On Tue, Jun 17, 2008 at 02:07:37PM +0200, Jan Mette <jan.mette@berlin.de> wrote:
Another example: Our kdebase-workspace package is split into 3 pkgs: kdebase-workspace (binaries), kdebase-workspace-docs and kdebase-workspace-icons... When we rebuild this package, we just bump the kdebase-workspace pkg, but not the two with docs and icons... So, for us, there is definitely a need to vary pkgrels between the split pkgs...
it's your decision but we tried this and it did not work. in fact we just tried to do something like: we had foo-1.0-1 and libfoo-1.0-1 then we had an libfoo-specific problem. so we had libfoo-1.0-2 and foo-1.0-1 then we backported a bugfix from upstream cvs that changed the api, and we had: libfoo-1.0-3 and foo-1.0-2 and then libfoo-1.0-2 was incompatible with foo-1.0-2 there are two workarounds for this: - add proper dependency info this is doable but users will complain about buggy deps and they have reason. this is just illogical - bump foo to 1.0-3 as well. then the question from users will be where is 1.0-2, just like you ask upstream where is 1.0.2 when you see only 1.0.1 and 1.0.3. it's far more easier if you don't mess with different pkgvers/pkgrels for subpackages. of course technically it's doable, just like with pkgdecss, but i would not recommend it.