-----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@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx - -- Igor Raits <ignatenkobrain@xxxxxxxxxxxxxxxxx> -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7X3hIACgkQEV1auJxc Hh4/SBAAta3Au3oyBA72koUfKaMhvw8/XcT4FHMcJNiInpyobYFNSMmAvjJPj2/L tIefm2tPmtqSv03OjnIaeENVNT+eNiCcHljDvnT4x8fFySRn+r9Qvs+A7PU7zAIc 11q2WD+wzinFeSuf62Y+tvIVb1TPPdBrJqSsh+f/v97YK94ZhTpzfBa1C7ysZOds JXSZo5Sh0OqLDmi876YdpCZnYn3DAbqmkCfMJJ5RNWDGu5KbN35s4utBZSTfqt73 bEh/TPZ22RkNYpPQU/70CJkBcJXVJMS6JzZIOUhvSE5ITvYTg/E26vL4AmZS0rY+ eWbaR2N7V7GDhVe5MM8wpHStF8KxGajROeqllR3OF0w8lKlxIPItj9DI7DHuBEtI IFJUq8L1OLnFP3PR3pkn6a8wNwLTVWmAy44lR4NCMn7J9SbvRcjmAuFx9O2IprIH wG9vmVo4Q2Olvh8HJYr09xAFGKzmqlZnBTgiPGwcHl5O4EkygPAEdHD1EcEtkeRv Ony/fi4HX2f3B1YKdlEoqs7sDsMvLPEJzw32MftMIdBBo8q/0Xba/EQMya76ihrh ai5AFAOiqpoNzN6FjceIEGm3G0n2YquLMW++uVPIB0VJLYmoXBuGZD02LLxUfTzm VFnSjqnyVMkNaavxJf2SyCPkRY8xqN3exymh0vQUOVPmWPAbywI= =hJ35 -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
