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/r...
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/r...
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(a)lists.fedoraproject.org
>>>> To unsubscribe send an email to
>>>> devel-leave(a)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(a)lists.fedoraproject.org
>>> To unsubscribe send an email to
>>> devel-leave(a)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(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org