RFC: Fedora revamp proposal

[Michael Scherer]

Le lundi 11 mars 2013 à 03:44 +0100, Kevin Kofler a écrit :
> Michael Scherer wrote:

> > 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".

Given the target of rawhide, I expect people to be able to clean the
unneeded packages after a while. Heck, like they do for packages that
got orphaned and removed.

And do you have any number ? Cause I have been running distro with such
policy and "many MiB" still doesn't make much to my experience, so
provides credible numbers if you wish to make your point , especially
when talking to people who have seen this policy in action.

> > The priority for rawhide should be having something that work first.
> 
> It feels really wrong to design a whole library packaging policy around 
> Rawhide. 

I do not see how it would feel wrong to try to fix a issue by changing a
policy. And I do not see why Rawhide should be less important than
stable for that matter.

> 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.

Usually, you have 3 months for branched to make sure everything is
rebuild and that there is only 1 version of a lib. Have you read what
Olav said, about "packages without source rpm will be removed after 2
weeks", and "then they show as having "broken deps in report" ?

The script is not that hard to do, you can even get the one I wrote from
svn ( http://svnweb.mageia.org/adm/puppet/modules/mirror_cleaner/ ).

Not to mention that having the old version for a few days doesn't mean
people cannot go ahead and rebuild their packages as they do now, the
only difference is for users, since this permit to have a installable
rawhide for a more longer period of time.


> > 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.

yum history undo work fine for simple and medium cases, but after a
while due to the level of churn on stable release, it can break :
http://pastebin.com/Bdt6ngy2

And there is nothing broken on my system according to yum check all.

> > 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!)

That's just package naming. If you are more concerned by the name of the
rpm than by having users, there is priority issue.


> > 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.

That's still not explaining. 2 is not "several". And "I do not accept
solution" is not the same as "there is no solution".

-- 
Michael Scherer