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, 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 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

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 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

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

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

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

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

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

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 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, 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 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, 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

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

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