[opensuse-packaging] Renaming a package

http://en.opensuse.org/Package_Dependencies#Renaming_a_package recommends: Provides: pac = 1.0 Obsoletes: pac <= 1.0 But that will make rpmlint complain with: "<newpac>: W: self-obsoletion <pac> <= <version> obsoletes <pac> = <version> The package obsoletes itself. This is known to cause errors in various tools and should thus be avoided, usually by using appropriately versioned Obsoletes and/or Provides and avoiding unversioned ones." Someone that is more sure than me about how RPM manages all this could correct it? Or fix rpmlint if the warning makes no sense. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hi, try Provides: pac = 1.0 Obsoletes: pac < 1.0 Am 17.02.2011 09:57, schrieb Cristian Morales Vega:
http://en.opensuse.org/Package_Dependencies#Renaming_a_package recommends:
Provides: pac = 1.0 Obsoletes: pac <= 1.0
But that will make rpmlint complain with:
"<newpac>: W: self-obsoletion <pac> <= <version> obsoletes <pac> = <version> The package obsoletes itself. This is known to cause errors in various tools and should thus be avoided, usually by using appropriately versioned Obsoletes and/or Provides and avoiding unversioned ones."
Someone that is more sure than me about how RPM manages all this could correct it? Or fix rpmlint if the warning makes no sense.
-- Christian --------------------------------------------------- Der ultimative shop für Sportbekleidung und Zubehör http://www.sc24.de --------------------------------------------------- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

2011/2/17 Christian <chris@computersalat.de>:
try
Provides: pac = 1.0 Obsoletes: pac < 1.0
I'm not so worried about making an specific package work as I'm about having wrong documentation. Are you sure that will trigger the update from pac 1.0 to newpack 1.1? Notice you are no longer "obsoleting" pac 1.0. The docs say "Strictly speaking, giving the old package name in the Provides: field is only needed if another package requires the old package name". From that I understand it's the Obsoletes the thing that triggers the update. But this seems to be in contradiction with "However, the Provides: entry triggers the selection of the new package during update. It is this field which tells, I'm taking over for the old package. The Obsoletes: just ensures an atomic replacement so that no dependencies are broken". If a leaf package is renamed, will it be updated with only the Provides? I can't test right now, but I don't think so. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Am Donnerstag 17 Februar 2011, 10:26:59 schrieb Cristian Morales Vega:
2011/2/17 Christian <chris@computersalat.de>:
try
Provides: pac = 1.0 Obsoletes: pac < 1.0
I'm not so worried about making an specific package work as I'm about having wrong documentation. Are you sure that will trigger the update from pac 1.0 to newpack 1.1? Notice you are no longer "obsoleting" pac 1.0.
The docs say "Strictly speaking, giving the old package name in the Provides: field is only needed if another package requires the old package name". From that I understand it's the Obsoletes the thing that triggers the update. But this seems to be in contradiction with "However, the Provides: entry triggers the selection of the new package during update. It is this field which tells, I'm taking over for the old package. The Obsoletes: just ensures an atomic replacement so that no dependencies are broken".
If a leaf package is renamed, will it be updated with only the Provides? I can't test right now, but I don't think so.
It does not provide 1.0 - it provides 1.1 so you want
Provides: pac = 1.1 Obsoletes: oldpacname <= 1.0
-- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Am 17.02.2011 10:26, schrieb Cristian Morales Vega:
2011/2/17 Christian <chris@computersalat.de>:
try
Provides: pac = 1.0 Obsoletes: pac < 1.0
I'm not so worried about making an specific package work as I'm about having wrong documentation. Are you sure that will trigger the update from pac 1.0 to newpack 1.1? Notice you are no longer "obsoleting" pac 1.0.
The docs say "Strictly speaking, giving the old package name in the Provides: field is only needed if another package requires the old package name". From that I understand it's the Obsoletes the thing that triggers the update. But this seems to be in contradiction with "However, the Provides: entry triggers the selection of the new package during update. It is this field which tells, I'm taking over for the old package. The Obsoletes: just ensures an atomic replacement so that no dependencies are broken".
If a leaf package is renamed, will it be updated with only the Provides? I can't test right now, but I don't think so.
Hmm, I'm also wondering sometimes about it if I ever got it right I forgot it again ;-) But is the correct usage not like: Provides: pac = %{version} Obsoletes: pac <= LATEST_AVAILABLE_VERSION_WITH_NAME_PAC ? I guess that's only correct if the version increases with the name change though. Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hello, On Feb 17 11:04 Wolfgang Rosenauer wrote (excerpt):
Hmm, I'm also wondering sometimes about it if I ever got it right I forgot it again ;-)
Same for me. This whole stuff is too awkward to be done right.
But is the correct usage not like: Provides: pac = %{version} Obsoletes: pac <= LATEST_AVAILABLE_VERSION_WITH_NAME_PAC
With the various repositories of the openSUSE build service there is no such thing as one known "LATEST_AVAILABLE_VERSION_WITH_NAME_PAC". To be more on the safe side regarding whatever third-party packages form whatever third-party repositories I would use Provides: pac = %{version} Obsoletes: pac < %{version} so that it would silently replace any older "pac" from any repository. 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-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

2011/2/17 Johannes Meixner <jsmeix@suse.de>:
On Feb 17 11:04 Wolfgang Rosenauer wrote (excerpt):
But is the correct usage not like: Provides: pac = %{version} Obsoletes: pac <= LATEST_AVAILABLE_VERSION_WITH_NAME_PAC
With the various repositories of the openSUSE build service there is no such thing as one known "LATEST_AVAILABLE_VERSION_WITH_NAME_PAC".
To be more on the safe side regarding whatever third-party packages form whatever third-party repositories I would use
Provides: pac = %{version} Obsoletes: pac < %{version}
so that it would silently replace any older "pac" from any repository.
Fedora does something similar: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Freplacin... But it would be more like Provides: pac = %{version} Obsoletes: pac < FIRST_VERSION_WITH_NAME_NEWPAC , without using the %{version} macro in Obsoletes, to avoid "gratuitously polluting the version space upwards". The "version isn't increased with the name change" problem Wolfgang points out would be solved with the release number. But we usually aren't in control of it in the OBS. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/17/2011 12:28 PM, Cristian Morales Vega wrote:
Provides: pac = %{version} Obsoletes: pac < FIRST_VERSION_WITH_NAME_NEWPAC
, without using the %{version} macro in Obsoletes, to avoid "gratuitously polluting the version space upwards".
The "version isn't increased with the name change" problem Wolfgang points out would be solved with the release number. But we usually aren't in control of it in the OBS.
The Osoletes: version has to be lower than the Provides: version otherwise it causes noise in the package manager, I've actually considered trying out epoch: which fedora uses but we don't but a fictitious version number with a .999 added can also do the job if neccessary. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hello, On Feb 17 11:28 Cristian Morales Vega wrote (excerpt):
To be more on the safe side regarding whatever third-party packages form whatever third-party repositories I would use
Provides: pac = %{version} Obsoletes: pac < %{version}
so that it would silently replace any older "pac" from any repository.
Fedora does something similar: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Freplacin...
But it would be more like
Provides: pac = %{version} Obsoletes: pac < FIRST_VERSION_WITH_NAME_NEWPAC
Assume there is another repository where pac is provided with FIRST_VERSION_WITH_NAME_NEWPAC < pac's_version < newpac's_version Then such an installed pac might not be silently replaced by newpac because the Obsoletes does not apply. Or would such an installed pac be silently replaced by newpac because the Provides does apply? Or might whatever installer software (not plain rpm) run mad because the above looks contradicting to its built-in logic? I don't know. This whole stuff is too obscure for my simple mind... Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex

On 02/17/2011 11:26 AM, Cristian Morales Vega wrote:
2011/2/17 Christian <chris@computersalat.de>:
try
Provides: pac = 1.0 Obsoletes: pac < 1.0
I'm not so worried about making an specific package work as I'm about having wrong documentation. Are you sure that will trigger the update from pac 1.0 to newpack 1.1? Notice you are no longer "obsoleting" pac 1.0.
The docs say "Strictly speaking, giving the old package name in the Provides: field is only needed if another package requires the old package name". This is in the case of a -devel package rename like libfoo-devel becoming foo-devel or vice versa.
From that I understand it's the Obsoletes the thing that triggers the update. But this seems to be in contradiction with "However, the Provides: entry triggers the selection of the new package during update. It is this field which tells, I'm taking over for the old package. The Obsoletes: just ensures an atomic replacement so that no dependencies are broken".
If a leaf package is renamed, will it be updated with only the Provides? I can't test right now, but I don't think so.
The old wiki page used the incorrect way which results in an rpmlint error about obsoleting and providing the same version, the new wiki has the correct syntax where the obsoleted package has the previous version to the provided package. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

2011/2/17 Dave Plater <davejplater@gmail.com>:
The old wiki page used the incorrect way which results in an rpmlint error about obsoleting and providing the same version, the new wiki has the correct syntax where the obsoleted package has the previous version to the provided package.
Correct for the pretty table. But the text behind it says that's the quick way, and recommends a scheme that makes rpmlint complain. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hello, On Feb 17 11:38 Cristian Morales Vega wrote (excerpt):
But the text behind it says that's the quick way, and recommends a scheme that makes rpmlint complain.
Any text which I did read regarding RPM dependencies was convoluted stuff of obsure jargon. This seems to indicate that the root cause why nobody can describe it in a comprehensible way is that it actually is convoluted and obsure in RPM plus whatever installer software. A longer time ago I did it exactly as described (which worked perfectly with plain RPM) but it became a nightmare when using the installer software and the "solution" was plain wrong RPM dependencies to make it work for the installer software. In the end: Better don't ask for "the right way how to do it" but just do what seems to work o.k. for you. 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-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/17/2011 12:38 PM, Cristian Morales Vega wrote:
2011/2/17 Dave Plater <davejplater@gmail.com>:
The old wiki page used the incorrect way which results in an rpmlint error about obsoleting and providing the same version, the new wiki has the correct syntax where the obsoleted package has the previous version to the provided package.
Correct for the pretty table. But the text behind it says that's the quick way, and recommends a scheme that makes rpmlint complain.
There's something strange going on with the packaging portal, there used to be "naming conventions" which as I pointed out in another message the old wiki had the incorrect information and there was the correct information in a new wiki, which now seems to be obsoleted by one which is very vague. Another thing that's missing is "language bindings naming conventions" I needed redland python bindings for the LV2 plugin packages I'm pushing to 11.4 so I built them within the existing redland package and named them redland-python etc. This resulted in a scolding from the factory reviewer about not following openSUSE "language bindings naming conventions" with a hint that it should be "perl-redland". I suppose I could have asked on this list first, in fact I did ask for somebody to look at the package at the end of January but nobody did and a search for wiki info was fruitless. Now somethings gone missing about package upgrade paths. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Le jeudi 17 février 2011, à 09:57 +0100, Cristian Morales Vega a écrit :
http://en.opensuse.org/Package_Dependencies#Renaming_a_package recommends:
Provides: pac = 1.0 Obsoletes: pac <= 1.0
Here's how I usually do it now: - first, just renaming: Provides: pac = %{version} # FIXME bla bla bla remove <= on version upgrade Obsoletes: pac <= %{version} - when there's a new version: Provides: pac = %{version} Obsoletes: pac < %{version} The <= is important at first, I believe, since you're not sure the old package will be removed if it's < (since the installed version is higher than the obsoleted one). 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

Hello, On Feb 17 12:09 Vincent Untz wrote (excerpt):
Provides: pac = %{version} Obsoletes: pac <= %{version}
This causes a RPMLINT warning that it obsoletes itself which may cause whatever failure of package installation tools (up to atomic blasts if I imagine correctly what the text in those RPMLINT warning tries to tell me ;-) 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-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Le jeudi 17 février 2011, à 12:18 +0100, Johannes Meixner a écrit :
Hello,
On Feb 17 12:09 Vincent Untz wrote (excerpt):
Provides: pac = %{version} Obsoletes: pac <= %{version}
This causes a RPMLINT warning that it obsoletes itself which may cause whatever failure of package installation tools (up to atomic blasts if I imagine correctly what the text in those RPMLINT warning tries to tell me ;-)
I know. But I trust our zypp-based tools to do the right thing. The rpmlint warning is right in general; but in this case, we can't do anything else, afaik. 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 02/17/2011 01:18 PM, Johannes Meixner wrote:
Hello,
On Feb 17 12:09 Vincent Untz wrote (excerpt):
Provides: pac = %{version} Obsoletes: pac <= %{version}
This causes a RPMLINT warning that it obsoletes itself which may cause whatever failure of package installation tools (up to atomic blasts if I imagine correctly what the text in those RPMLINT warning tries to tell me ;-)
Kind Regards Johannes Meixner
It really happens, you get very loud noises from the installation system. If the Provides: = %version and Obsoletes: < %version doesn't work properly especially when you have packman packages to contend with then Obsoletes: < %{version}.9999 or something similar does the trick. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hello, On Feb 17 14:37 Dave Plater wrote (excerpt):
... especially when you have packman packages to contend with ...
Ahh! It seems I was absolutely right with my dark foreboding that the various repositories cause new and unfamiliar issues so that it is in general a good idea to try to be on the safe side regarding whatever packages form whatever third-party repositories. And Vincent Untz might be wrong - at least in some cases - when he "trust our zypp-based tools to do the right thing"... By the way: I already had a nightmare lesson with packman packages. 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-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (7)
-
Christian
-
Cristian Morales Vega
-
Dave Plater
-
Johannes Meixner
-
Ralf Lang
-
Vincent Untz
-
Wolfgang Rosenauer