RFC: Fedora revamp proposal

[Kevin Kofler]

Michael Scherer wrote:
> keeping unused library is not worst that keeping old perl modules.

Conceptually, keeping old Perl modules is just as bad. Our Perl packaging 
does not keep old versions lying around either!

Practically, libraries tend to be a lot larger than Perl modules.

> A few wasted mega of disk space do not seems to be big problem if that
> permit to have more people on rawhide, faster tests and faster feedback.

Old libraries accumulate over the lifetime of an installation, eating many 
MiB, not just "a few".

> The priority for rawhide should be having something that work first.

It feels really wrong to design a whole library packaging policy around 
Rawhide. The focus needs to be on making stable releases clean without 
useless legacy compatibility baggage, and Rawhide needs to be the 
development bed for that. Compatibility libraries only make sense where the 
packages cannot be ported to the new version in time for the release.

> And I think the problem could be solved ( and in fact, it is already a
> problem we have for those that install something, then remove the main
> software without cleaning deps ).

The solution for that problem is called yum history undo, and it doesn't 
solve the old library problem.

> We should not refuse  the idea on the ground that this is too complex
> for some users to understand the concept of soname. Either they don't,
> and then we should just hide libraries from the UI at some point ( and
> that's already done ), because with or without soname, that will not
> change anything, or they are able to understand and then we should not
> treat them as they couldn't.

IMHO, having KDE 3 libs versioned as kdelibs4 is totally unacceptable. It's 
really confusing. (The only worse way to do things is to append an 
unreadable suffix for the C++ ABI to that as Debian did with "kdelibs4c2a". 
But if you insist on keeping old ABIs around for any and all ABI changes in 
Rawhide, we'll eventually end up with the same mess!)

> So 2 drawbacks do not seems much, or at least not "several".
> Can you maybe explain others issues so we can find a solution that work
> fine ?

Sorry, there is just no solution that can make soname-suffixed libraries 
work.

        Kevin Kofler