Packages renames

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Packages renames

Stephan Kulow-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Bernhard Walle-2
* 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Packages renames

Stephan Kulow-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Michael Schroeder-4
In reply to this post by Stephan Kulow-3
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                                   [hidden email]
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Lars Vogdt
In reply to this post by Stephan Kulow-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Thorsten Kukuk
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/      [hidden email]
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Lars Vogdt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Thorsten Kukuk
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/      [hidden email]
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Dominique Leuenberger-2
>>> On 07.05.2008 at 12:33, Thorsten Kukuk <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Michael Matz
In reply to this post by Lars Vogdt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Lars Vogdt
In reply to this post by Thorsten Kukuk
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Michael Matz
In reply to this post by Dominique Leuenberger-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Michal Marek
In reply to this post by Stephan Kulow-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Dominique Leuenberger-2
In reply to this post by Michael Matz
>>> On 07.05.2008 at 12:43, Michael Matz <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Michael Schroeder-4
In reply to this post by Michael Matz
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                                   [hidden email]
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

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


Ciao,
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Stephan Kulow-3
In reply to this post by Michal Marek
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

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?

Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Stephan Kulow-3
In reply to this post by Michael Matz
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages renames

Stephan Kulow-3
In reply to this post by Michal Marek
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: [hidden email]
For additional commands, e-mail: [hidden email]

12