In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM.
Regards, Daniel
On 3.5.2018 12:10, Daniel P. Berrangé wrote> How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo
RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM.
Last time I've asked it was impossible. See https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
On 3.5.2018 12:17, Miro Hrončok wrote:
Last time I've asked it was impossible. See https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
Sorry, the link should have been:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
"DPB" == Daniel P Berrangé berrange@redhat.com writes:
DPB> How can I get the auto-generated DPB> libvirt-daemon-driver-libxl-debuginfo RPM to have an "Obsoletes: DPB> libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems DPB> impossible, meaning users with debuginfo have a broken upgrade DPB> path.
It's not technically _impossible_; the debuginfo subpackage is generated using the %_debuginfo_template macro, which gets magically inserted into the specfile just before %install.
The problem, of course, is that redefining it is a pain and since all of the subpackages are generated from the one template, you can't necessarily add something for just one package. Maybe you can with some nasty conditionals; I haven't checked. If I was in a situation where I just had to do this, I'd probably do it in Lua.
- J<
On Thu, May 3, 2018 at 6:10 AM Daniel P. Berrangé berrange@redhat.com wrote:
In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM.
How is this creating upgrade problems? debuginfo packages do not require the main packages at all.
On Sun, May 06, 2018 at 11:00:00AM +0000, Neal Gompa wrote:
On Thu, May 3, 2018 at 6:10 AM Daniel P. Berrangé berrange@redhat.com wrote:
In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM.
How is this creating upgrade problems? debuginfo packages do not require the main packages at all.
I have the debuginfo RPMs installed locally and the upgrade process wants to install the new debuginfo RPMs to replace them. Whether they have a dep on the main non-debuginfo packages is tangential to that.
Regards, Daniel
Because was bitten by this and there is not clear guideline, I have tried to draft something here:
https://pagure.io/packaging-committee/pull-request/988
Vít
Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a):
In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM.
Regards, Daniel
Other possibility is to modify DNF to not touch such packages. Not sure if that would be better. Or is there already some functionality which would exclude the package from dnf transaction, something like:
~~~ # This package won't be installed, but will obsolete other packages Provides: libsolv-self-destruct-pkg()
~~~
we use in fedora-obsolete-packages?
Vít
Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a):
Because was bitten by this and there is not clear guideline, I have tried to draft something here:
https://pagure.io/packaging-committee/pull-request/988
Vít
Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a):
In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM.
Regards, Daniel
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote:
Other possibility is to modify DNF to not touch such packages. Not sure if that would be better. Or is there already some functionality which would exclude the package from dnf transaction, something like:
# This package won't be installed, but will obsolete other packages Provides: libsolv-self-destruct-pkg()we use in fedora-obsolete-packages?
Since they do not block the upgrades, does it really matter? However, I agree that DNF removing packages that are not present in upgrade repo and blocking the upgrade, should be removed automatically.
Vít
Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a):
Because was bitten by this and there is not clear guideline, I have tried to draft something here:
https://pagure.io/packaging-committee/pull-request/988
Vít
Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a):
In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl- debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM.
Regards, Daniel
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Wed, Jun 03, 2020 at 07:29:54PM +0200, Igor Raits wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote:
Other possibility is to modify DNF to not touch such packages. Not sure if that would be better. Or is there already some functionality which would exclude the package from dnf transaction, something like:
# This package won't be installed, but will obsolete other packages Provides: libsolv-self-destruct-pkg()we use in fedora-obsolete-packages?
Since they do not block the upgrades, does it really matter? However, I agree that DNF removing packages that are not present in upgrade repo and blocking the upgrade, should be removed automatically.
That's the distinction between upgrade and distro-sync.
-- Petr
Dne 03. 06. 20 v 19:29 Igor Raits napsal(a):
On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote:
Other possibility is to modify DNF to not touch such packages. Not sure if that would be better. Or is there already some functionality which would exclude the package from dnf transaction, something like:
# This package won't be installed, but will obsolete other packages Provides: libsolv-self-destruct-pkg()we use in fedora-obsolete-packages?
Since they do not block the upgrades, does it really matter?
They block updates. The subpackage -debuginfo requires the main package. While there is update for the main package, there is obviously not update for the subpackages. Therefore the subpackage -debuginfo packages will block the upgrade forever. This is the same issue why we have fedora-obsolete-packages. However the difference is that we typically don't care about -debuginfos, because they are magically generated and they are always parallel installable.
However, I agree that DNF removing packages that are not present in upgrade repo and blocking the upgrade, should be removed automatically.
Actually, the -debuginfo package could be possibly treated as installonly packages. But even install only packages are updated, if I am not mistaken. So it would be probably better if DNF completely ignored them.
Vít
Vít
Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a):
Because was bitten by this and there is not clear guideline, I have tried to draft something here:
https://pagure.io/packaging-committee/pull-request/988
Vít
Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a):
In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl- debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM.
Regards, Daniel
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, 2020-06-04 at 10:56 +0200, Vít Ondruch wrote:
Dne 03. 06. 20 v 19:29 Igor Raits napsal(a):
On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote:
Other possibility is to modify DNF to not touch such packages. Not sure if that would be better. Or is there already some functionality which would exclude the package from dnf transaction, something like:
# This package won't be installed, but will obsolete other packages Provides: libsolv-self-destruct-pkg()we use in fedora-obsolete-packages?
Since they do not block the upgrades, does it really matter?
They block updates. The subpackage -debuginfo requires the main package.
I don't think that it is true anymore, starting with Fedora 27. https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
❯ sudo dnf repoquery --repo=rawhide-debuginfo --requires gnome-shell- debuginfo --quiet | wc -l 0
While there is update for the main package, there is obviously not update for the subpackages. Therefore the subpackage -debuginfo packages will block the upgrade forever. This is the same issue why we have fedora-obsolete-packages. However the difference is that we typically don't care about -debuginfos, because they are magically generated and they are always parallel installable.
However, I agree that DNF removing packages that are not present in upgrade repo and blocking the upgrade, should be removed automatically.
Actually, the -debuginfo package could be possibly treated as installonly packages. But even install only packages are updated, if I am not mistaken. So it would be probably better if DNF completely ignored them.
Vít
Vít
Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a):
Because was bitten by this and there is not clear guideline, I have tried to draft something here:
https://pagure.io/packaging-committee/pull-request/988
Vít
Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a):
In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl- debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen- debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM.
Regards, Daniel
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
Dne 04. 06. 20 v 11:25 Igor Raits napsal(a):
On Thu, 2020-06-04 at 10:56 +0200, Vít Ondruch wrote:
Dne 03. 06. 20 v 19:29 Igor Raits napsal(a):
On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote:
Other possibility is to modify DNF to not touch such packages. Not sure if that would be better. Or is there already some functionality which would exclude the package from dnf transaction, something like:
# This package won't be installed, but will obsolete other packages Provides: libsolv-self-destruct-pkg()we use in fedora-obsolete-packages?
Since they do not block the upgrades, does it really matter?
They block updates. The subpackage -debuginfo requires the main package.
I don't think that it is true anymore, starting with Fedora 27. https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
❯ sudo dnf repoquery --repo=rawhide-debuginfo --requires gnome-shell- debuginfo --quiet | wc -l 0
gnome-shell is not subpackage but main package.
Try this:
~~~
$ rpm -qpR https://kojipkgs.fedoraproject.org//packages/ruby/2.7.1/131.fc33/x86_64/ruby... rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 ruby-debuginfo(x86-64) = 2.7.1-131.fc33
$ rpm -qpP https://kojipkgs.fedoraproject.org//packages/ruby/2.7.1/131.fc33/x86_64/ruby... debuginfo(build-id) = 03222f2590f7d7b09b1b7bb6587ece4dc89c84a4 ruby-debuginfo = 2.7.1-131.fc33 ruby-debuginfo(x86-64) = 2.7.1-131.fc33 ~~~
If we decided to drop the ruby-libs subpackage for whatever reason, the ruby-debuginfo would not be possible to update.
Vít
While there is update for the main package, there is obviously not update for the subpackages. Therefore the subpackage -debuginfo packages will block the upgrade forever. This is the same issue why we have fedora-obsolete-packages. However the difference is that we typically don't care about -debuginfos, because they are magically generated and they are always parallel installable.
However, I agree that DNF removing packages that are not present in upgrade repo and blocking the upgrade, should be removed automatically.
Actually, the -debuginfo package could be possibly treated as installonly packages. But even install only packages are updated, if I am not mistaken. So it would be probably better if DNF completely ignored them.
Vít
Vít
Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a):
Because was bitten by this and there is not clear guideline, I have tried to draft something here:
https://pagure.io/packaging-committee/pull-request/988
Vít
Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a):
In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl- debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen- debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM.
Regards, Daniel
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-
Daniel P. Berrangé -
Igor Raits -
Jason L Tibbitts III -
Miro Hrončok -
Neal Gompa -
Petr Pisar -
Vít Ondruch