[opensuse-packaging] Packages renames
Hi, Yesterday I learned something new and I think, so will you now: most of us (including me) did package renames the wrong way and the documentation in the wiki on it is unfortunately not very clear. So let me get this straight and I hope everyone will use it correctly from now on: oldpac.spec: Name: oldpac Version: 1.0 baselibs.conf: oldpac You want to rename it to newpac on update, what do you have to do? newpac.spec: Name: newpac Version: 1.1 Provides: oldpac <= 1.0 Obsoletes: oldpac <= 1.0 baselibs.conf: newpac obsoletes "oldpac-<targettype> <= 1.0" provides "oldpac-<targettype> <= 1.0" That's it - please always use <= with the latest version oldpac had, everything else is most likely wrong. And don't forget about the baselibs. Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Stephan Kulow [2008-05-07 09:00]:
did package renames the wrong way and the documentation in the wiki on it is unfortunately not very clear.
Did you update the documentation? Bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Mittwoch, 7. Mai 2008 schrieb Bernhard Walle:
* Stephan Kulow [2008-05-07 09:00]:
did package renames the wrong way and the documentation in the wiki on it is unfortunately not very clear.
Did you update the documentation?
No, it's made of pictures. But there are surely a lot of people being able to use xfig subscribed here, that can do that. Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, May 07, 2008 at 10:39:35AM +0200, Stephan Kulow wrote:
Am Mittwoch, 7. Mai 2008 schrieb Bernhard Walle:
* Stephan Kulow [2008-05-07 09:00]:
did package renames the wrong way and the documentation in the wiki on it is unfortunately not very clear.
Did you update the documentation?
No, it's made of pictures. But there are surely a lot of people being able to use xfig subscribed here, that can do that.
ENOURL. http://en.opensuse.org/Upgrade_Dependencies -- 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 Wed, May 07, 2008 at 09:00:11AM +0200, Stephan Kulow wrote:
newpac.spec: Name: newpac Version: 1.1 Provides: oldpac <= 1.0
In most cases provides should use "=", not "<=". 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 Mittwoch, 7. Mai 2008 09:00:11 Stephan Kulow wrote:
Provides: oldpac <= 1.0
imho wrong: should be Provides: oldpac = 1.0
baselibs.conf: newpac provides "oldpac-<targettype> <= 1.0"
provides "oldpac-<targettype> = 1.0
That's it - please always use <= with the latest version oldpac had, everything else is most likely wrong. And don't forget about the baselibs.
No: Provides should only contain a "=" and not a "<=" - otherwise please point me to your new RPM documentation. With kind regards, Lars --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, May 07, Lars Vogdt wrote:
On Mittwoch, 7. Mai 2008 09:00:11 Stephan Kulow wrote:
Provides: oldpac <= 1.0
imho wrong: should be Provides: oldpac = 1.0
baselibs.conf: newpac provides "oldpac-<targettype> <= 1.0"
provides "oldpac-<targettype> = 1.0
That's it - please always use <= with the latest version oldpac had, everything else is most likely wrong. And don't forget about the baselibs.
No: Provides should only contain a "=" and not a "<=" - otherwise please point me to your new RPM documentation.
Hm, if Provides only contains a "=", which version number should I add? The one from openSUSE 10.1? The one from openSUSE 10.2? The one from openSUSE 10.3? The one from SLE10 SPX? Or do you wish to tell me, I'm no longer able to update from SLE10 to SLE11? Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SUSE LINUX Products GmbH Maxfeldstr. 5 D-90409 Nuernberg -------------------------------------------------------------------- Key fingerprint = 8C6B FD92 EE0F 42ED F91A 6A73 6D1A 7F05 2E59 24BB --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mittwoch, 7. Mai 2008 11:20:11 Thorsten Kukuk wrote:
Hm, if Provides only contains a "=", which version number should I add? The one from openSUSE 10.1? The one from openSUSE 10.2? The one from openSUSE 10.3? The one from SLE10 SPX?
Or do you wish to tell me, I'm no longer able to update from SLE10 to SLE11?
In an ideal world, the obsolete/provides-version should contain the exact version number of the obsoleted old package. So in the given example this would be: Obsoletes: oldpac <= 1.0 Provides: oldpac = 1.0 But in the past we agree also with Obsoletes oldpac <= %{version} Provides: oldpac = %{version} ...in the hope that a "reborn" oldpac package would start with a higher version number than the current newpac... Lars --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, May 07, Lars Vogdt wrote:
On Mittwoch, 7. Mai 2008 11:20:11 Thorsten Kukuk wrote:
Hm, if Provides only contains a "=", which version number should I add? The one from openSUSE 10.1? The one from openSUSE 10.2? The one from openSUSE 10.3? The one from SLE10 SPX?
Or do you wish to tell me, I'm no longer able to update from SLE10 to SLE11?
In an ideal world, the obsolete/provides-version should contain the exact version number of the obsoleted old package.
AGAIN:
if Provides only contains a "=", which version number should I add? The one from openSUSE 10.1? The one from openSUSE 10.2? The one from openSUSE 10.3? The one from SLE10 SPX?
Thanks for reading what I wrote, Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SUSE LINUX Products GmbH Maxfeldstr. 5 D-90409 Nuernberg -------------------------------------------------------------------- Key fingerprint = 8C6B FD92 EE0F 42ED F91A 6A73 6D1A 7F05 2E59 24BB --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 07.05.2008 at 12:33, Thorsten Kukuk <kukuk@suse.de> wrote: On Wed, May 07, Lars Vogdt wrote:
On Mittwoch, 7. Mai 2008 11:20:11 Thorsten Kukuk wrote:
Hm, if Provides only contains a "=", which version number should I add? The one from openSUSE 10.1? The one from openSUSE 10.2? The one from openSUSE 10.3? The one from SLE10 SPX?
Or do you wish to tell me, I'm no longer able to update from SLE10 to SLE11?
In an ideal world, the obsolete/provides-version should contain the exact version number of the obsoleted old package.
AGAIN:
if Provides only contains a "=", which version number should I add? The one from openSUSE 10.1? The one from openSUSE 10.2? The one from openSUSE 10.3? The one from SLE10 SPX?
I think the Provides can easily be only with "="; and providing only one version with a package is not that wrong. This works as long as the Obsoletes contains ALL the versions that are obsoleted (<=). then the upgrade will work in any case. dominique --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Wed, 7 May 2008, Dominique Leuenberger wrote:
I think the Provides can easily be only with "="; and providing only one version with a package is not that wrong. This works as long as the Obsoletes contains ALL the versions that are obsoleted (<=).
then the upgrade will work in any case.
If there are versioned Requires from 3rd-party packages this will break. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 07.05.2008 at 12:43, Michael Matz <matz@suse.de> wrote: Hi,
On Wed, 7 May 2008, Dominique Leuenberger wrote:
I think the Provides can easily be only with "="; and providing only one version with a package is not that wrong. This works as long as the Obsoletes contains ALL the versions that are obsoleted (<=).
then the upgrade will work in any case.
If there are versioned Requires from 3rd-party packages this will break.
In case this Requires: xyz = 1.0 then yes. BUT: if it's for example a library (they are most common for renames at the moment, due to the SH-Policy), it is rather difficult to say if ALL lower versions are provided. It might in fact be that only a subset of the oldpac versions are compatible (think about libfoo1..libfoo<n>... they used to be called libfoo). IMHO, It's a thing of the update solver to inform the user that a specific packet has to be removed for not having all the Requirements full-filled anymore. A 3rd party is most likely going to re-lease his package for a newer SLE Version again. Maybe I also trust to much in 3rd parties... Dominique --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mittwoch, 7. Mai 2008 11:33:23 Thorsten Kukuk wrote:
In an ideal world, the obsolete/provides-version should contain the exact version number of the obsoleted old package.
AGAIN:
if Provides only contains a "=", which version number should I add? The one from openSUSE 10.1?
oldpac-version 0.8
The one from openSUSE 10.2?
oldpac-version 0.9
The one from openSUSE 10.3?
oldpac-version 1.0
The one from SLE10 SPX?
oldpac-version 0.85 Now you want to obsolete all packages above in openSUSE 11.0: newpac-version xy Provides: oldpac = 1.0 Obsoletes: oldpac <= 1.0 ^^^^ Packages requiring "oldpac" at least in version 1.0 would be fine with Provides: oldpac = 1.0 The oldpac can be deleted because Obsoletes: oldpac <= 1.0 would fit all the other versions above. So the mix is the solution: the Provides is only necessary to make other packages happy which require oldpac. The Obsoletes allows RPM to install newpac instead of oldpac (and this for all versions <= 1.0).
Thanks for reading what I wrote,
dito ;-) Lars --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Wed, 7 May 2008, Lars Vogdt wrote:
On Mittwoch, 7. Mai 2008 11:20:11 Thorsten Kukuk wrote:
Hm, if Provides only contains a "=", which version number should I add? The one from openSUSE 10.1? The one from openSUSE 10.2? The one from openSUSE 10.3? The one from SLE10 SPX?
Or do you wish to tell me, I'm no longer able to update from SLE10 to SLE11?
In an ideal world, the obsolete/provides-version should contain the exact version number of the obsoleted old package. So in the given example this would be:
Obsoletes: oldpac <= 1.0 Provides: oldpac = 1.0
What Thorsten is trying to say is, that this complicates updating from older than the last box/product, to a point where the package maintainer probably will make an error that breaks such updating. Suppose there's a package oldpac with these versions: oS 10.1 : oldpac 1.1 oS 10.2 : oldpac 1.3 oS 10.3 : oldpac 1.4 SLE10 : oldpac 1.2 Now, what version should be provided in newpac (going into oS 11.0)? With the current suggestion it would be: Provides: oldpac = 1.4 That package will also go into SLE11. But updating from SLE10 to SLE11 would require a Provides: oldpac = 1.2 (as that was the version in SLE10). So the question is, how to handle this? An easy work around is to provide a whole halfrange (Provides: oldpac <= 1.4), which obviously breaks if not all features of _all_ older versions are there. Another suggestion would be to add multiple provides: Provides: oldpac = 1.2 Provides: oldpac = 1.4 That's cumbersome and most people will get this wrong. Especially because the set of those to-be-added provides depends on the set of older products from which we'd like to update. Including things like SP's and side products. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, May 07, 2008 at 11:41:52AM +0200, Michael Matz wrote:
What Thorsten is trying to say is, that this complicates updating from older than the last box/product, to a point where the package maintainer probably will make an error that breaks such updating. Suppose there's a package oldpac with these versions:
oS 10.1 : oldpac 1.1 oS 10.2 : oldpac 1.3 oS 10.3 : oldpac 1.4 SLE10 : oldpac 1.2
Now, what version should be provided in newpac (going into oS 11.0)? With the current suggestion it would be:
Provides: oldpac = 1.4
That package will also go into SLE11. But updating from SLE10 to SLE11 would require a Provides: oldpac = 1.2 (as that was the version in SLE10).
Why do you think so? If there was no rename, we have the same scenario: oS 10.1 : pac 1.1 oS 10.2 : pac 1.3 oS 10.3 : pac 1.4 SLE10 : pac 1.2 pac 1.x will automatically get "Provides: pac = 1.x" by rpmbuild, and nobody is complaining about that. 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
Hi, On Wed, 7 May 2008, Michael Schroeder wrote:
Why do you think so? If there was no rename, we have the same scenario:
oS 10.1 : pac 1.1 oS 10.2 : pac 1.3 oS 10.3 : pac 1.4 SLE10 : pac 1.2
pac 1.x will automatically get "Provides: pac = 1.x" by rpmbuild, and nobody is complaining about that.
A good point, indeed. Should be no problem then (IOW versioned requires of 3rdparty would already break and that this doesn't happen proves we can do what is suggested). Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Mittwoch 07 Mai 2008 schrieb Michael Matz:
Hi,
On Wed, 7 May 2008, Michael Schroeder wrote:
Why do you think so? If there was no rename, we have the same scenario:
oS 10.1 : pac 1.1 oS 10.2 : pac 1.3 oS 10.3 : pac 1.4 SLE10 : pac 1.2
pac 1.x will automatically get "Provides: pac = 1.x" by rpmbuild, and nobody is complaining about that.
A good point, indeed. Should be no problem then (IOW versioned requires of 3rdparty would already break and that this doesn't happen proves we can do what is suggested).
OK, we just did a little offlist evaluation of the problem. The problem is very interesting: This was broken in our distribution upgrade algorithm for a very long time and well hidden by the "delete unmaintained packages" feature. Now that this feature is off and I'm actually testing what packages are left, it turned out that our packages (howto) is not written in sync with what our software does. And I got convinced yesterday by the arguments Thorsten uses, that the software is right and the packages wrong. Now we met and Michael's arguments convinced me that rpm/smart/satsolver disagree with libzypp. It's very interesting just how much confusion around this topic exists - And that the documenation is confusing doesn't really help either, but now we'll first see what the status is before I do anything :) Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, beg your pardon for the disturbing, but who can advise me a proper person (from Novell I guess) who can check my packages for compliance with all policies and procedures? Another question is about some kind of requirements, policies & procedures, instructions or any other approved way to include some of my packages to the upcoming release of OpenSUSEi (11.1). Do we have an approved instructions / best practice approach for it? Here is the pattern I kindly ask to check: http://download.opensuse.org/repositories/home:/dmitry_serpokryl:/Enlightenm... And if you wish to take a look at the things without installation - here's the LiveCD: http://sda.scwlab.com/suse-11.0-live-iso.i686-2.5.1.iso Brief summary and login credentials are on the 'main page': http://sda.scwlab.com/ LiveCD contain EFL applications (based on Enlightenment Foundation Libraries) from the repo above, Enlightenment-DR17, Enlightenment-DR16, IceWM and some other packages. The full list of packages installed for LiveCD is here: http://sda.scwlab.com/list_of_installed_packages.tar.bz2 I'll highly appreciate any response. Thank you. My Best Regards, Dmitry --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday 15 July 2008, sda wrote:
beg your pardon for the disturbing, but who can advise me a proper person (from Novell I guess) who can check my packages for compliance with all policies and procedures?
http://en.opensuse.org/Packaging/SUSE_Package_Conventions is a great start.
Another question is about some kind of requirements, policies & procedures, instructions or any other approved way to include some of my packages to the upcoming release of OpenSUSEi (11.1).
I can only remember 3 requirements: one requirement: Find somebody within Novell who is willing to co-maintain the package with you and do the novell-internal bits (like setting up the devel repository in the OBS, accepts your OBS submission requests, reviews them and submits them to factory). Unfortunately there is no real procedure for finding a person yet. The best way is to formally ask on this mailing list if somebody wants to step up to be that person for you. We have an e17n maintainer internally. if all else fails you should try contacting him. The other requirement is that you're willing to maintain the package, make sure that it builds and that you accept bugreports against it and promise to work on them as your time permits. The last one is that you've signed the opensuse guiding principles and want to become (or already are) an opensuse member. Thanks for asking, I hope those requirements are not a problem for you :) Greetings, Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dirk Mueller wrote: | On Tuesday 15 July 2008, sda wrote: [...] | The last one is that you've signed the opensuse guiding principles and want to | become (or already are) an opensuse member. openSUSE membership is granted on existing contributions, not on future ones nor on the intention of contributing :) cheers - -- ~ -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ ~ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> ~ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIffLNr3NMWliFcXcRAud3AJ9UXtTCFgpXoav52rZtR775MIOHWwCdEhaL rtZQUREb0drldJUdaat2bng= =rMfq -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday 16 July 2008, Pascal Bleser wrote:
| The last one is that you've signed the opensuse guiding principles and want to | become (or already are) an opensuse member. openSUSE membership is granted on existing contributions, not on future ones nor on the intention of contributing :)
thats why I said "want to become" :) Greetings, Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11:30 Wed 16 Jul , Dirk Mueller wrote:
On Tuesday 15 July 2008, sda wrote:
beg your pardon for the disturbing, but who can advise me a proper person (from Novell I guess) who can check my packages for compliance with all policies and procedures?
http://en.opensuse.org/Packaging/SUSE_Package_Conventions is a great start.
Another question is about some kind of requirements, policies & procedures, instructions or any other approved way to include some of my packages to the upcoming release of OpenSUSEi (11.1).
I can only remember 3 requirements:
one requirement: Find somebody within Novell who is willing to co-maintain the package with you and do the novell-internal bits (like setting up the devel repository in the OBS, accepts your OBS submission requests, reviews them and submits them to factory). Unfortunately there is no real procedure for finding a person yet. The best way is to formally ask on this mailing list if somebody wants to step up to be that person for you. We have an e17n maintainer internally. if all else fails you should try contacting him.
The other requirement is that you're willing to maintain the package, make sure that it builds and that you accept bugreports against it and promise to work on them as your time permits.
The last one is that you've signed the opensuse guiding principles and want to become (or already are) an opensuse member.
Thanks for asking, I hope those requirements are not a problem for you :)
Greetings, Dirk
Thanks Dirk for an answer. May I kindly ask here, in opensuse-packaging mailing list, is there a person from Novell who wish to co-maintain EFL/Enlightenment-DR17 packages (and include them into the next release of OpenSUSE)? If someone wish to evaluate the benefits of it - here's an Enlightenment LiveCD: http://sda.scwlab.com/ Please choose 'Enlightenment' as your session for login (the default is 'E16'). EFL/Enlightenment repo is here: http://download.opensuse.org/repositories/home:/dmitry_serpokryl:/Enlightenm... And I'm talking only about core minimum (see the pattern): http://download.opensuse.org/repositories/home:/dmitry_serpokryl:/Enlightenm... Please let me know if you need any additional info. Regards, Dmitry --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Stephan Kulow wrote:
You want to rename it to newpac on update, what do you have to do?
newpac.spec: Name: newpac Version: 1.1 Provides: oldpac <= 1.0 Obsoletes: oldpac <= 1.0
So if some other package Requires: oldpac = 1.0, the installer will happily replace oldpac-1.0 with newpac-1.1 and possibly break the dependent package. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Mittwoch 07 Mai 2008 schrieb Michal Marek:
Stephan Kulow wrote:
You want to rename it to newpac on update, what do you have to do?
newpac.spec: Name: newpac Version: 1.1 Provides: oldpac <= 1.0 Obsoletes: oldpac <= 1.0
So if some other package Requires: oldpac = 1.0, the installer will happily replace oldpac-1.0 with newpac-1.1 and possibly break the dependent package.
That's the whole point of a package rename, that newpac is now what oldpac used to be. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Stephan Kulow wrote:
Am Mittwoch 07 Mai 2008 schrieb Michal Marek:
Stephan Kulow wrote:
You want to rename it to newpac on update, what do you have to do?
newpac.spec: Name: newpac Version: 1.1 Provides: oldpac <= 1.0 Obsoletes: oldpac <= 1.0 So if some other package Requires: oldpac = 1.0, the installer will happily replace oldpac-1.0 with newpac-1.1 and possibly break the dependent package.
That's the whole point of a package rename, that newpac is now what oldpac used to be.
So the whole point of a package rename is to _silently_ break packages that require a specific version of the old package? Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Mittwoch 07 Mai 2008 schrieb Michal Marek:
Stephan Kulow wrote:
Am Mittwoch 07 Mai 2008 schrieb Michal Marek:
Stephan Kulow wrote:
You want to rename it to newpac on update, what do you have to do?
newpac.spec: Name: newpac Version: 1.1 Provides: oldpac <= 1.0 Obsoletes: oldpac <= 1.0
So if some other package Requires: oldpac = 1.0, the installer will happily replace oldpac-1.0 with newpac-1.1 and possibly break the dependent package.
That's the whole point of a package rename, that newpac is now what oldpac used to be.
So the whole point of a package rename is to _silently_ break packages that require a specific version of the old package? Hmm, good point. This is getting worse and worse :)
Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, 7 May 2008, Stephan Kulow wrote:
Am Mittwoch 07 Mai 2008 schrieb Michal Marek:
Stephan Kulow wrote:
Am Mittwoch 07 Mai 2008 schrieb Michal Marek:
Stephan Kulow wrote:
You want to rename it to newpac on update, what do you have to do?
newpac.spec: Name: newpac Version: 1.1 Provides: oldpac <= 1.0 Obsoletes: oldpac <= 1.0
So if some other package Requires: oldpac = 1.0, the installer will happily replace oldpac-1.0 with newpac-1.1 and possibly break the dependent package.
That's the whole point of a package rename, that newpac is now what oldpac used to be.
So the whole point of a package rename is to _silently_ break packages that require a specific version of the old package? Hmm, good point. This is getting worse and worse :)
The provides part shouldn't be different than if it was not a rename but a virtual package (see gcc with it's libstdc++43 package for example). So: Name: newpac Version: 1.0 Provides: oldpac = 1.0 Obsoletes: oldpac <= 1.0 And Name: newpac Version: 1.1 Obsoletes: oldpac <= 1.0 but not provide oldpac = 1.0 as that would be wrong, or oldpac = 1.1 as that would cause problems if we rename it back to oldpac. Basically this "special-casing" of upgrading in yast/zypp is wrong from the start IMHO. Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, May 07, 2008 at 03:19:27PM +0200, Richard Guenther wrote:
Name: newpac Version: 1.1 Obsoletes: oldpac <= 1.0
but not provide oldpac = 1.0 as that would be wrong, or oldpac = 1.1 as that would cause problems if we rename it back to oldpac.
What problems would that cause? 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 Wed, 7 May 2008, Michael Schroeder wrote:
On Wed, May 07, 2008 at 03:19:27PM +0200, Richard Guenther wrote:
Name: newpac Version: 1.1 Obsoletes: oldpac <= 1.0
but not provide oldpac = 1.0 as that would be wrong, or oldpac = 1.1 as that would cause problems if we rename it back to oldpac.
What problems would that cause?
old: Name: newpac Version: 1.1 Provides: oldpac = 1.1 Obsoletes: oldpac <= 1.0 new: Name: oldpac Version: 1.1 Provides: newpac = 1.1 Obsoletes: newpac <= 1.1 At some point in time yast didn't catch the update from newpac to oldpac. You say the new solver now disambiguates this based on that one obsoletes is <= 1.0 and one is newpac <= 1.1? Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, May 07, 2008 at 03:32:10PM +0200, Richard Guenther wrote:
old: Name: newpac Version: 1.1 Provides: oldpac = 1.1 Obsoletes: oldpac <= 1.0
new: Name: oldpac Version: 1.1 Provides: newpac = 1.1 Obsoletes: newpac <= 1.1
At some point in time yast didn't catch the update from newpac to oldpac.
I think that this works for the solver, but I'm not so sure about the dist upgrade algorithm. (Of course, the provides should actually be %{version}-%{release}, but maybe that's too confusing) 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 Wed, 7 May 2008, Michael Schroeder wrote:
On Wed, May 07, 2008 at 03:32:10PM +0200, Richard Guenther wrote:
old: Name: newpac Version: 1.1 Provides: oldpac = 1.1 Obsoletes: oldpac <= 1.0
new: Name: oldpac Version: 1.1 Provides: newpac = 1.1 Obsoletes: newpac <= 1.1
At some point in time yast didn't catch the update from newpac to oldpac.
I think that this works for the solver, but I'm not so sure about the dist upgrade algorithm.
(Of course, the provides should actually be %{version}-%{release}, but maybe that's too confusing)
A question from the outside world: Shouldn't be Provides be equal to the new package version: Name: newpac Version: 1.1 Release: 12 Provides: oldpac = %{version}-%{release} Obsoletes: oldpac <= 1.0 This would be the only variant, which is equal to not renaming the package. And thus simulates a normal update. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday 07 May 2008, Michael Schroeder wrote:
Version: 1.1 Obsoletes: oldpac <= 1.0 but not provide oldpac = 1.0 as that would be wrong, or oldpac = 1.1 as that would cause problems if we rename it back to oldpac. What problems would that cause?
if it is renamed back without a version upgrade (change). Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dirk Mueller wrote:
On Wednesday 07 May 2008, Michael Schroeder wrote:
Version: 1.1 Obsoletes: oldpac <= 1.0 but not provide oldpac = 1.0 as that would be wrong, or oldpac = 1.1 as that would cause problems if we rename it back to oldpac. What problems would that cause?
if it is renamed back without a version upgrade (change).
We could add the release string to the provides / obsoletes, which is under our control. I.e. in Richard's example: old: Name: newpac Version: 1.1 Release: 12 Provides: oldpac = 1.1 Obsoletes: oldpac <= 1.0 new: Name: oldpac Version: 1.1 Release: 13 Provides: newpac = 1.1-13 Obsoletes: newpac <= 1.1-12 Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Stephan Kulow escribió:
Hmm, good point. This is getting worse and worse :)
Yes, Im puzzled now :-) whatever is the right way, the documentation should be updated, at least Im working based on what the docs says..ouch :-P -- "Progress is possible only if we train ourselves to think about programs without thinking of them as pieces of executable code.” - Edsger W. Dijkstra Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
Am Mittwoch, 14. Mai 2008 schrieb Cristian Rodríguez:
Stephan Kulow escribió:
Hmm, good point. This is getting worse and worse :)
Yes, Im puzzled now :-) whatever is the right way, the documentation should be updated, at least Im working based on what the docs says..ouch :-P
The documentation is about right. It's just missing prominent examples: xxbit packages and versions that stay the same on package renames. BTW: I'm hoping you're not planning to submit package renames at this point. Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Stephan Kulow escribió:
BTW: I'm hoping you're not planning to submit package renames at this point.
Nope, not at this stage :) -- "Progress is possible only if we train ourselves to think about programs without thinking of them as pieces of executable code.” - Edsger W. Dijkstra Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
participants (15)
-
Bernhard Walle -
Cristian Rodríguez -
Dirk Mueller -
Dirk Stoecker -
Dominique Leuenberger -
Lars Vogdt -
Martin Vidner -
Michael Matz -
Michael Schroeder -
Michal Marek -
Pascal Bleser -
Richard Guenther -
sda -
Stephan Kulow -
Thorsten Kukuk