Yep, we'll alter the package deps as time allows. Thanks for the comments.

Like Harald says make one user visible package which installs a working application. If this working application consists of separate modules, there is of course problem with managing upgrades with h-a-m, but that's life with maemo. You just need to update user visible package with version dependencies to updated modules.

here is my suggestion: make a new package mbarcode-core in a non user categorie without dependency to any plugin. This contains what mbarcode now is. Make mbarcode just depend on core and whatever plugin you want. Let all plugins depend on core. This would solve your problem, right?

Sorry, I know you guys have worked hard on this and have done some really great work, but I'm in agreement with the testers that the dependencies are backwards. While I understand your rationale, I think it would be best to have a bare-bones mBarcode package with the plug-ins dependent on it.

Yes the deps are a bit weird, but this was thought necessary to ensure that plugins are installed when mBarcode is installed (as from user feedback if the deps are the other way round, and the user just installs mBarcode they can't really do much with it).

Can one have circular deps? I.e. mBarcode depends on the plugin meta package and each actual plugin package depends on mBarcode?

Assuming this would work, I will add a >= version to the dependency to prevent Harald Schmitt's experience of installing a newer plugin on an old-api version of mBarcode (I'm ever hopeful that the new version of mBarcode will also make it here, but the promotion interface also dislikes complex dependencies it would appear).

The reason the dependencies are this way around is because it was the only way to assure that certain plugins were installed with the application, without including them into the mbarcode package itself. Which again was chosen this way to make it possible to push new versions of plugins without updating the whole mbarcode package.

It worked good when the packages were in extras-devel, but any comments on this approach are greatly appreciated though :)

dependencies are weird. mbarcode depends on plugins. It should be the other way round.

Bork. Let us know if it's fixed and/or needs retesting.

--

KT

Testing. Sorry about the noise.

--

KT

Contains only shared library for mbarcode(?), but the actual application isn't installed through dependencies. From users perspective I didn't install anything.

Please use Maemo-Display-Name http://wiki.maemo.org/Packaging#Pretty_names

Please write short "self contained" description. Such as "Read barcodes using the camera" (actually I don't know what this does).

Comments apply probably to other plugins too.

Yes, there is some issue with importing the latest version of mBarcode (i.e. the one with which this version of the wifi plugin belongs). Apologies, I'm trying to get this sorted out ASAP.

Makes current testing version of mbarcode not working anymore