[opensuse-packaging] Renaming a package: what about lang and debuginfo?
Hello, I'm attempting to rename Xfce Panel Plugin packages in openSUSE to follow the name xfce4-foo-plugin instead of xfce4-panel-plugin-foo. I understand that this is needed in the spec file. Provides: xfce4-panel-plugin-foo = %{version} Obsoletes: xfce4-panel-plugin-foo < %{version} What do I need to do about the -lang, -debuginfo and -debugsource packages which seem to be automatically generated? Thank you! -- Maurizio Galli (MauG) Xfce Team https://en.opensuse.org/Portal:Xfce -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 11/07/2019 17:10, Maurizio Galli (MauG) wrote:
Hello, I'm attempting to rename Xfce Panel Plugin packages in openSUSE to follow the name xfce4-foo-plugin instead of xfce4-panel-plugin-foo.
I understand that this is needed in the spec file. Provides: xfce4-panel-plugin-foo = %{version} Obsoletes: xfce4-panel-plugin-foo < %{version}
What do I need to do about the -lang, -debuginfo and -debugsource packages which seem to be automatically generated?
This should be automatically done, as all those packages are directly associated with xfce4-foo-plugin and xfce4-panel-plugin-foo -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 2019-07-11 11:33, Simon Lees wrote:
Hello, I'm attempting to rename Xfce Panel Plugin packages in openSUSE to follow the name xfce4-foo-plugin instead of xfce4-panel-plugin-foo.
I understand that this is needed in the spec file. Provides: xfce4-panel-plugin-foo = %{version} Obsoletes: xfce4-panel-plugin-foo < %{version}
What do I need to do about the -lang, -debuginfo and -debugsource packages which seem to be automatically generated?
This should be automatically done, as all those packages are directly associated with xfce4-foo-plugin and xfce4-panel-plugin-foo
Should, but isn't. 12:23 a4:../openSUSE/sp # rpm -q --obsoletes xfdesktop xfce4-desktop < 4.12.5 12:23 a4:../openSUSE/sp # rpm -q --obsoletes xfdesktop-lang 12:23 a4:../openSUSE/sp # rpm -q --obsoletes xfdesktop-debuginfo 12:23 a4:../openSUSE/sp # -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 7/11/19 6:24 PM, Jan Engelhardt wrote:
On Thursday 2019-07-11 11:33, Simon Lees wrote:
Hello, I'm attempting to rename Xfce Panel Plugin packages in openSUSE to follow the name xfce4-foo-plugin instead of xfce4-panel-plugin-foo.
I understand that this is needed in the spec file. Provides: xfce4-panel-plugin-foo = %{version} Obsoletes: xfce4-panel-plugin-foo < %{version}
What do I need to do about the -lang, -debuginfo and -debugsource packages which seem to be automatically generated?
This should be automatically done, as all those packages are directly associated with xfce4-foo-plugin and xfce4-panel-plugin-foo
Should, but isn't.
12:23 a4:../openSUSE/sp # rpm -q --obsoletes xfdesktop xfce4-desktop < 4.12.5 12:23 a4:../openSUSE/sp # rpm -q --obsoletes xfdesktop-lang 12:23 a4:../openSUSE/sp # rpm -q --obsoletes xfdesktop-debuginfo 12:23 a4:../openSUSE/sp #
Yes I noticed that too and I am not sure whether or not it is a problem. Also, because the old and new package share the same version (no update upstream, only the package), the old package does not seem to be replaced by the new renamed one. Does this mean that will have to delete the old package from Factory immediately to avoid duplicates? Is there a nicer way to deal with it? Thank you! -- Maurizio Galli (MauG) Xfce Team https://en.opensuse.org/Portal:Xfce -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, Am Donnerstag, 11. Juli 2019, 15:52:57 CEST schrieb Maurizio Galli (MauG):
Also, because the old and new package share the same version (no update upstream, only the package), the old package does not seem to be replaced by the new renamed one. Does this mean that will have to delete the old package from Factory immediately to avoid duplicates? Is there a nicer way to deal with it?
Isn't this exactly what the package version, or "Release" as it is called in the spec file, is for; to indicate that the package changed despite the upstream still being the same? I know the build service does magic things to the Release field. But AFAIR it only ever increments, so bumping it sufficiently in the spec of the new package should give you the desired result. Kind Regards, Matthias -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
On 7/12/19 3:51 AM, Matthias Bach wrote:
Hi,
Am Donnerstag, 11. Juli 2019, 15:52:57 CEST schrieb Maurizio Galli (MauG):
Also, because the old and new package share the same version (no update upstream, only the package), the old package does not seem to be replaced by the new renamed one. Does this mean that will have to delete the old package from Factory immediately to avoid duplicates? Is there a nicer way to deal with it?
Isn't this exactly what the package version, or "Release" as it is called in the spec file, is for; to indicate that the package changed despite the upstream still being the same?
I know the build service does magic things to the Release field. But AFAIR it only ever increments, so bumping it sufficiently in the spec of the new package should give you the desired result.
Kind Regards, Matthias
Thank you Matthias! Bumping up the Realease and using the following worked: Provides: xfce4-panel-plugin-pulseaudio = %{version}-%{release} Obsoletes: xfce4-panel-plugin-pulseaudio < %{version}-%{release} Installing the new package replaces the old one. However the subpackages such as xfce4-panel-plugin-pulseaudio-lang created by the macro %lang_package is not affected. Neither the -debuginfo and -debugsource packages are. -- Maurizio Galli (MauG) Xfce Team https://en.opensuse.org/Portal:Xfce -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 12/07/2019 05:21, Matthias Bach wrote:
Hi,
Am Donnerstag, 11. Juli 2019, 15:52:57 CEST schrieb Maurizio Galli (MauG):
Also, because the old and new package share the same version (no update upstream, only the package), the old package does not seem to be replaced by the new renamed one. Does this mean that will have to delete the old package from Factory immediately to avoid duplicates? Is there a nicer way to deal with it?
Isn't this exactly what the package version, or "Release" as it is called in the spec file, is for; to indicate that the package changed despite the upstream still being the same?
I know the build service does magic things to the Release field. But AFAIR it only ever increments, so bumping it sufficiently in the spec of the new package should give you the desired result.
Almost, except obs built packages also contain a "build" number that increments with each build of the same version so you generally don't have to worry about it (unless your swapping between repo's where the build number in the "old" repo can be higher then the one in the "new" repo). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 7/12/19 2:19 PM, Simon Lees wrote:
On 12/07/2019 05:21, Matthias Bach wrote:
Hi,
Am Donnerstag, 11. Juli 2019, 15:52:57 CEST schrieb Maurizio Galli (MauG):
Also, because the old and new package share the same version (no update upstream, only the package), the old package does not seem to be replaced by the new renamed one. Does this mean that will have to delete the old package from Factory immediately to avoid duplicates? Is there a nicer way to deal with it?
Isn't this exactly what the package version, or "Release" as it is called in the spec file, is for; to indicate that the package changed despite the upstream still being the same?
I know the build service does magic things to the Release field. But AFAIR it only ever increments, so bumping it sufficiently in the spec of the new package should give you the desired result.
Almost, except obs built packages also contain a "build" number that increments with each build of the same version so you generally don't have to worry about it (unless your swapping between repo's where the build number in the "old" repo can be higher then the one in the "new" repo).
Because I'm introducing a new package to rename another one, OBS assigns the new package a lower number than the old one, thus the update is not triggered. Giving a higher Release number manually in this case seems to be necessary. -- Maurizio Galli (MauG) Xfce Team https://en.opensuse.org/Portal:Xfce -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 7/12/19 2:19 PM, Simon Lees wrote:
On 12/07/2019 05:21, Matthias Bach wrote:
Hi,
Am Donnerstag, 11. Juli 2019, 15:52:57 CEST schrieb Maurizio Galli (MauG):
Also, because the old and new package share the same version (no update upstream, only the package), the old package does not seem to be replaced by the new renamed one. Does this mean that will have to delete the old package from Factory immediately to avoid duplicates? Is there a nicer way to deal with it?
Isn't this exactly what the package version, or "Release" as it is called in the spec file, is for; to indicate that the package changed despite the upstream still being the same?
I know the build service does magic things to the Release field. But AFAIR it only ever increments, so bumping it sufficiently in the spec of the new package should give you the desired result.
Almost, except obs built packages also contain a "build" number that increments with each build of the same version so you generally don't have to worry about it (unless your swapping between repo's where the build number in the "old" repo can be higher then the one in the "new" repo).
I think I got it to behave correctly. See example https://build.opensuse.org/package/show/X11:xfce:next/xfce4-pulseaudio-plugi... -lang package is now properly replaced and lingering old debuginfo package is removed -- Maurizio Galli (MauG) Xfce Team https://en.opensuse.org/Portal:Xfce -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Jan Engelhardt -
Matthias Bach -
Maurizio Galli (MauG) -
Simon Lees