[opensuse-packaging] RPM Epoch
Hi, do we have a policy about using the RPM epoch versions? I thought the rule was not to use it, but the conventions mention nothing: http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.8._Version_Tag Or do we stick to Just Say No from the upstream docs? http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Freitag 16 Januar 2009 11:39:13 Martin Vidner wrote:
Hi,
do we have a policy about using the RPM epoch versions?
yes, don't use them. The reason behind is that it just moves the problem to the next level.
I thought the rule was not to use it, but the conventions mention nothing: http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.8._Version_Tag
Maybe this should just get added there :)
Or do we stick to Just Say No from the upstream docs? http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner
Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
-- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le vendredi 16 janvier 2009, à 13:16 +0100, Adrian Schröter a écrit :
On Freitag 16 Januar 2009 11:39:13 Martin Vidner wrote:
Hi,
do we have a policy about using the RPM epoch versions?
yes, don't use them. The reason behind is that it just moves the problem to the next level.
I thought the rule was not to use it, but the conventions mention nothing: http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.8._Version_Tag
Maybe this should just get added there :)
Indeed. But to add this there, we should probably explain how to handle some cases where epoch is used in other distros so people don't feel lost. So, any idea what are the usual problems where epoch is solved, and what are the recommended solutions? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
So, any idea what are the usual problems where epoch is solved, and what are the recommended solutions?
I think you have no more possibilities than just rename the package. Anicka -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 1/16/2009 at 2:01 PM, Vincent Untz <vuntz@opensuse.org> wrote: So, any idea what are the usual problems where epoch is solved, and what are the recommended solutions?
I think a typical problem might be that you created / published a version with a completely broken version tag (typo in the spec file). so instead of having VersionL 1.0.1 you wrote Version: 10.1 In this case of course, the user will never ever get an update anymore until the package really reaches this version. This is a use-case where Epoch can help you out... (as it's just an added version information in front of the real version). Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mardi 20 janvier 2009, à 15:37 +0100, Dominique Leuenberger a écrit :
On 1/16/2009 at 2:01 PM, Vincent Untz <vuntz@opensuse.org> wrote: So, any idea what are the usual problems where epoch is solved, and what are the recommended solutions?
I think a typical problem might be that you created / published a version with a completely broken version tag (typo in the spec file).
so instead of having VersionL 1.0.1 you wrote Version: 10.1
In this case of course, the user will never ever get an update anymore until the package really reaches this version.
Yep, that's the only use case I'm aware of.
This is a use-case where Epoch can help you out... (as it's just an added version information in front of the real version).
But... what about the policy to not use Epoch? :-) Is it okay in this case? (if yes, we should specify this) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Jan 20, 2009 at 03:46:48PM +0100, Vincent Untz wrote:
Le mardi 20 janvier 2009, à 15:37 +0100, Dominique Leuenberger a écrit :
On 1/16/2009 at 2:01 PM, Vincent Untz <vuntz@opensuse.org> wrote: So, any idea what are the usual problems where epoch is solved, and what are the recommended solutions?
I think a typical problem might be that you created / published a version with a completely broken version tag (typo in the spec file).
so instead of having VersionL 1.0.1 you wrote Version: 10.1
In this case of course, the user will never ever get an update anymore until the package really reaches this version.
Yep, that's the only use case I'm aware of.
This is a use-case where Epoch can help you out... (as it's just an added version information in front of the real version).
But... what about the policy to not use Epoch? :-) Is it okay in this case? (if yes, we should specify this)
No, never use Epoch. You can never get rid of it again for this package. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, Jan 16, 2009 at 02:01:43PM +0100, Vincent Untz wrote:
Indeed. But to add this there, we should probably explain how to handle some cases where epoch is used in other distros so people don't feel lost.
We have a policy that the version scheme must not change in a released product (i.e. with the maintenance updates), so we don't need epochs in that case. For release updates (11.0 -> 11.1 and the like), the distupgrade algorithm has no problems with downgrading, so we also need to worry about epochs here. Are there any other uses? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Freitag 16 Januar 2009 schrieb Vincent Untz:
Le vendredi 16 janvier 2009, à 13:16 +0100, Adrian Schröter a écrit :
On Freitag 16 Januar 2009 11:39:13 Martin Vidner wrote:
Hi,
do we have a policy about using the RPM epoch versions?
yes, don't use them. The reason behind is that it just moves the problem to the next level.
I thought the rule was not to use it, but the conventions mention nothing: http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.8._Version_ Tag
Maybe this should just get added there :)
Indeed. But to add this there, we should probably explain how to handle some cases where epoch is used in other distros so people don't feel lost.
So, any idea what are the usual problems where epoch is solved, and what are the recommended solutions?
SUSE's solution is: the dup algorithm (from zypper dup or yast system update) will take any version from the distribution repository (most often the DVD) if the vendor stayed SUSE. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 1/20/2009 at 3:45 PM, Stephan Kulow <coolo@suse.de> wrote: SUSE's solution is: the dup algorithm (from zypper dup or yast system update) will take any version from the distribution repository (most often the DVD) if the vendor stayed SUSE.
I think we have more to consider than 'the distribution'. The BuildService as a powerful tool needs it's attention too. As written in another mail, a typical error might be to have the Version: tag mistyped (Version: 10.1 instead of Version: 1.0.1). The policy to not change version numbers do not apply on the OBS (I hope ;)) Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Jan 20, 2009 at 03:45:45PM +0100, Stephan Kulow wrote:
SUSE's solution is: the dup algorithm (from zypper dup or yast system update) will take any version from the distribution repository (most often the DVD) if the vendor stayed SUSE.
Not true, the vendor isn't considered. "dup" is like a fresh installation. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Jan 20, Michael Schroeder wrote:
On Tue, Jan 20, 2009 at 03:45:45PM +0100, Stephan Kulow wrote:
SUSE's solution is: the dup algorithm (from zypper dup or yast system update) will take any version from the distribution repository (most often the DVD) if the vendor stayed SUSE.
Not true, the vendor isn't considered. "dup" is like a fresh installation.
How does it handle "conflicting" packages that may or may not have a different feature set, like k3b from packman or videolan repo? Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 1/20/2009 at 3:59 PM, Olaf Hering <olh@suse.de> wrote: How does it handle "conflicting" packages that may or may not have a different feature set, like k3b from packman or videolan repo?
There is no k3b in videolan repo ;) i only contains videolan client and it's dependencies. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (9)
-
Adrian Schröter -
anicka＠suse.cz -
Dominique Leuenberger -
Marcus Meissner -
Martin Vidner -
Michael Schroeder -
Olaf Hering -
Stephan Kulow -
Vincent Untz