[opensuse-buildservice] different package versions for subpackages
Hi, I have a package which includes a subpackage where I want to have a different version number as for the main package. This basically seems to work until it comes to Release numbers. RPM seems to support the different versions correctly but the buildservice apparently has a problem with it as release numbers are always identical for all packages created from one source rpm which could lead to release numbers going down if main package version number gets increased while the subpackage version number stays the same. The Factory package which is affected is MozillaThunderbird which also creates the enigmail subpackage with its own version number. Is that really not possible or could that be fixed? Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Mittwoch, 5. August 2009 21:36:32 schrieb Wolfgang Rosenauer:
Hi,
I have a package which includes a subpackage where I want to have a different version number as for the main package. This basically seems to work until it comes to Release numbers.
RPM seems to support the different versions correctly but the buildservice apparently has a problem with it as release numbers are always identical for all packages created from one source rpm which could lead to release numbers going down if main package version number gets increased while the subpackage version number stays the same.
Yes, but why is that a problem ? All updaters compare $version-$release and never look on the release alone. So, if the version increases, it shouldn't be a problem when the release number goes done. bye adrian.
The Factory package which is affected is MozillaThunderbird which also creates the enigmail subpackage with its own version number.
Is that really not possible or could that be fixed?
Wolfgang
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am 05.08.2009 23:40, schrieb Adrian Schröter:
Am Mittwoch, 5. August 2009 21:36:32 schrieb Wolfgang Rosenauer:
Hi,
I have a package which includes a subpackage where I want to have a different version number as for the main package. This basically seems to work until it comes to Release numbers.
RPM seems to support the different versions correctly but the buildservice apparently has a problem with it as release numbers are always identical for all packages created from one source rpm which could lead to release numbers going down if main package version number gets increased while the subpackage version number stays the same.
Yes, but why is that a problem ?
All updaters compare $version-$release and never look on the release alone.
So, if the version increases, it shouldn't be a problem when the release number goes done.
So you misunderstood something. Example: MozillaThunderbird changes version from 3.0b3 to 3.0.0 enigmail stays on version 0.96a -> Release gets reset and enigmail gets "downgraded" Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Mittwoch, 5. August 2009 23:40:55 schrieb Wolfgang Rosenauer:
Am 05.08.2009 23:40, schrieb Adrian Schröter:
Am Mittwoch, 5. August 2009 21:36:32 schrieb Wolfgang Rosenauer:
Hi,
I have a package which includes a subpackage where I want to have a different version number as for the main package. This basically seems to work until it comes to Release numbers.
RPM seems to support the different versions correctly but the buildservice apparently has a problem with it as release numbers are always identical for all packages created from one source rpm which could lead to release numbers going down if main package version number gets increased while the subpackage version number stays the same.
Yes, but why is that a problem ?
All updaters compare $version-$release and never look on the release alone.
So, if the version increases, it shouldn't be a problem when the release number goes done.
So you misunderstood something. Example: MozillaThunderbird changes version from 3.0b3 to 3.0.0 enigmail stays on version 0.96a -> Release gets reset and enigmail gets "downgraded"
Ah, yes ... Sorry, I have no easy solution for that right now, that needs some thinking. (The release number is current only stored once per package, but not per sub package) A bugreport won't harm ... -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello, On Aug 5 23:40 Wolfgang Rosenauer wrote (shortened):
Example: MozillaThunderbird changes version from 3.0b3 to 3.0.0 enigmail stays on version 0.96a -> Release gets reset and enigmail gets "downgraded"
As a band-aid workaround you might maintain an artificial addendum to enigmail's version number like 0.96a.1 which you could manually increase whenever you increase the MozillaThunderbird version. Then when the release is reset, enigmail gets nevertheless artificially upgraded which results a needless update of enigmail on the end-users systems but perhaps this is an acceptable drawback of such a workaround? When Adrian has found a clean solution, you can get rid of the artificial addendum when enigmail's actual version number increases e.g. from 0.96a.1 to 0.97. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi, Am 06.08.2009 09:37, schrieb Johannes Meixner:
As a band-aid workaround you might maintain an artificial addendum to enigmail's version number like 0.96a.1 which you could manually increase whenever you increase the MozillaThunderbird version.
Then when the release is reset, enigmail gets nevertheless artificially upgraded which results a needless update of enigmail on the end-users systems but perhaps this is an acceptable drawback of such a workaround?
When Adrian has found a clean solution, you can get rid of the artificial addendum when enigmail's actual version number increases e.g. from 0.96a.1 to 0.97.
Yes, apparently I have to go for it for now. Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Wolfgang Rosenauer napsal(a):
So you misunderstood something. Example: MozillaThunderbird changes version from 3.0b3 to 3.0.0 enigmail stays on version 0.96a -> Release gets reset and enigmail gets "downgraded"
Note that MozillaThunderbird also gets downgraded in this case, so you are at least consistent ;-) $ zypper vcmp 3.0b3 3.0.0 3.0b3 is older than 3.0.0 Michal -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am 06.08.2009 13:17, schrieb Michal Marek:
Wolfgang Rosenauer napsal(a):
So you misunderstood something. Example: MozillaThunderbird changes version from 3.0b3 to 3.0.0 enigmail stays on version 0.96a -> Release gets reset and enigmail gets "downgraded"
Note that MozillaThunderbird also gets downgraded in this case, so you are at least consistent ;-) $ zypper vcmp 3.0b3 3.0.0 3.0b3 is older than 3.0.0
Ah, zypper vcmp is what I was looking for recently. Anyway you just proved that it's working correctly: "3.0b3 is older than 3.0.0" which is very true actually. Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 8/6/2009 at 13:17, Michal Marek <mmarek@suse.cz> wrote: Wolfgang Rosenauer napsal(a): So you misunderstood something. Example: MozillaThunderbird changes version from 3.0b3 to 3.0.0 enigmail stays on version 0.96a -> Release gets reset and enigmail gets "downgraded"
Note that MozillaThunderbird also gets downgraded in this case, so you are at least consistent ;-) $ zypper vcmp 3.0b3 3.0.0 3.0b3 is older than 3.0.0
Not really... 3.0b3 often represents 3.0 beta 3 :) so 'upgrading' to 3.0.0 is perfect the desired effect here.(not everybody uses [a-z] just to extend the space of available schemes). Dominique -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Michal Marek napsal(a):
Wolfgang Rosenauer napsal(a):
So you misunderstood something. Example: MozillaThunderbird changes version from 3.0b3 to 3.0.0 enigmail stays on version 0.96a -> Release gets reset and enigmail gets "downgraded"
Note that MozillaThunderbird also gets downgraded in this case, so you are at least consistent ;-) $ zypper vcmp 3.0b3 3.0.0 3.0b3 is older than 3.0.0
Hm, zypper gets it right (as my copy & paste shows), but rpm thinks 3.0b3 is newer: $ echo -e '3.0b3\n3.0.0' | /usr/lib/rpm/rpmsort 3.0.0 3.0b3 strange (but off-topic, sorry). Michal -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (5)
-
Adrian Schröter
-
Dominique Leuenberger
-
Johannes Meixner
-
Michal Marek
-
Wolfgang Rosenauer