On 6/16/21 6:26 PM, Kevin Kofler via devel wrote:
Otto Urpelainen wrote:
Also, if the intent is to get rid of the package completely, should not
adding it to fedora-obsolete-packages be required as well?
Why? Adding working packages to fedora-obsolete-packages forces removing
them from users' machines just because they are no longer in the repository.
That is a major disservice to the users. fedora-obsolete-packages makes
sense to use only when having the package still present actually breaks
something (and I personally think that it is unhelpful even in that case,
that is really what dnf --allowerasing is for, at least when we are talking
about package-level conflicts).
This is correct from the strict OS packaging point of view, but I think
we should be concerned about the accumulation of detritus: packages that
broke over time and simply do not work any more, for example like this one
https://bugzilla.redhat.com/show_bug.cgi?id=1490074
If unchecked, they make the system look like the FTP archives of last
century---strewn with broken, unmaintained stuff.
Of course new installs would not get these packages, only the old,
upgraded releases, so it only affects the people who update a lot.
Unfortunately, the tooling to clean it up is not that nice: the
%{RELEASE} RPM querytag is noisy so it needs to be touched up
rpm -qa --queryformat "%{release}\n" | perl -ne 'next unless /(fc\d+)/;
print "$1\n"' | sort | uniq -c | sort -n
1 fc28
2 fc30
3 fc29
14 fc31
15 fc32
33 fc33
4895 fc34
I sometimes run this on my systems and investigate why do I still have
FC2x package. Usually it is just some abandonware; in this case,
rpm -qa | grep fc2
glibc-arm-linux-gnu-2.27-4.fc29.x86_64
emacs-verilog-mode-531-13.fc29.noarch
emacs-php-mode-1.18.2-2.fc28.noarch
emacs-mew-6.8-2.fc29.x86_64
I think quietly deleting this stuff would be a little harsh, but maybe
it should be flagged in some way or at least easier to find and clean up?
BTW, I remember a discussion about obsolete gpg-pubkeys being a security
hole; again, cleaning them up would make sense. They are not included in
the list above---their %{release} sadly doesn't include the fedora
version; it is only informally (?) mentioned in the %{PACKAGER} and
%{SUMMARY} tags, making it hard to automate.
So, I'd like to at least propose that gpg-pubkeys packages have the
Fedora version they pertain to in their %{RELEASE} tag.
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
