Hans de Goede <j.w.r.degoede@...> writes:
> Did you even bother to read the entire proposal? Thats _exactly_ what
> the quick and dirty compat rule is for and without these rules we have
> things like a directfb update causing yum update to fail for days in a
> row, locking out most users of those o so vital security updates you're
> defending over here!
There's an easy fix for that:
yum install apt
This yum misdesign is the problem, not the soname changes.
> Also if such a security update is indeed done
> without any rule on howto properly handle / coordinate the soname change
> yum update will simply refuse to update, so the fix won't reach its
> intended audience (the end users).
The update will be done (doable at least, see above paragraph) a few hours
later when the reverse dependencies have been rebuilt. Compare this to the
compat packages situation where packages can be running against the vulnerable
version for months with nobody noticing (no "broken dependencies" report, for
example). Also, I want vulnerable packages the h*ll OFF my systems, not put in
a compat library!
I also generally don't want to have 2+ versions of each library cluttering my
hard disk, I want the packages to be updated to work with the latest, and
compat packages encourage exactly the opposite (and if I hit the hopefully
short window where the package is not rebuilt, instead of the library being
held back by apt-rpm, I'll get a compat library installed which will become
unnecessary only hours later, what a waste).
As for packages outside of Extras, I don't see why they shouldn't be rebuilt
too if Extras changes. As a packager of a few unofficial RPMs (which need some
cleanups before I can consider submitting them to Extras), I'll definitely
rebuild my RPMs as quickly as possible if a soname change in Extras requires
it, I don't see why Extras should be forced to provide compat libraries just to
allow me or others to be lazy.
> I do agree with you that "you can quickly end up with dozens of compat
> packages for the same library if it is _really_ rapidly changing"
> although that can easily be solved simply by:
> 1) asking maintainers to rebuild against the newest release
> 2) when releasing a new compat package remove all of the older compat
> package under the condition that no other package requires that older
> compat packages.
It can be solved much MORE simply by not introducing the compat library clutter
in the first place and just doing 1).
> And have you ever considered that if upstream changes the soname every
> few days that upstream then is seriously borked and you thus have a much
> bigger problem?
That's not something Extras can fix, so it's pointless to discuss here.
Kevin Kofler
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
