RFC: Fedora revamp proposal

[Kevin Kofler]

Michael Scherer wrote:
> 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.

My concern is not Rawhide, my concern is stable releases, especially if one 
upgrades from one release of Fedora to the next, then to the next etc. 
Fedora installations usually go through many upgrades, seeing how we release 
every 6 months. The problem with your proposal is that it is focused on 
Rawhide and ignores the impact on our actual releases.

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

Let's just take one of the few compatibility stacks we actually have to 
carry (because porting is far from trivial) as an example:

Name        : qt3
Version     : 3.3.8b
Release     : 41.fc17
Architecture: i686
Size        : 10467741

Name        : kdelibs3
Version     : 3.5.10
Release     : 42.fc17
Architecture: i686
Size        : 38669698

Name        : kdebase3
Version     : 3.5.10
Release     : 20.fc17
Architecture: i686
Size        : 17612161

Name        : kdebase3-libs
Version     : 3.5.10
Release     : 20.fc17
Architecture: i686
Size        : 1317496

Now multiply this by the number of soname bumps in the lifetime of an 
installation (just look at how often there are broken dependencies from a 
soname bump in the Rawhide reports) and see for yourself what doing the math 
leaves you with.

And in addition to the space issue, the old libraries would also be 
unmaintained and not get any security fixes. Maintaining all the old 
libraries with old sonames we ever releases just does not scale! See e.g. 
how upgrading to a new version for security reasons is explicitly listed as 
an exception to the policy of not bumping sonames in updates for stable 
releases in https://fedoraproject.org/wiki/Updates_Policy . It's all the 
more valid for Rawhide / between different releases (because each individual 
release goes EOL after ~13 months, Rawhide never goes EOL, nor does Fedora 
as a whole of course, so old stuff can get REALLY old). Leaving old 
unmaintained libraries lying around on user systems is a security disaster!

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

Because the whole purpose of Rawhide is to serve as a development bed for 
our stable releases. Rawhide is not and should not be our product, our 
releases are.

And in any cases, the releases do exist and you cannot entirely ignore their 
existence in your proposal.

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

Removing the old packages is not enough, you actually have to add Obsoletes 
to the current version if you don't want the old versions to accumulate on 
upgrades from one stable release to the next.

And who is going to enforce the Obsoletes? It WILL get forgotten more often 
than not. We already have enough broken upgrade paths as it stands.

In addition, having those Obsoletes will make users complain "Why does yum 
want to remove the compatibility library my [broken, not recompiled against 
the current Fedora] third-party package needs?", whereas not having them 
will make old (and unmaintained!) versions accumulate (as I said before). 
The best way to avoid such confusion is to avoid setting false expectations 
in the first place by just not version-suffixing the libraries.

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

Just to avoid a window of a few days, your proposal wants to introduce a 
version suffix we're stuck with forever. This seems very wrong.

> 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

The use case I was talking about is, you try the package, you don't like it, 
you uninstall it (before doing any other yum operations). Indeed, undoing an 
older yum operation may or may not work. But it's not the common case: Why 
would you want to uninstall a package after deciding you like it?

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

We have users right now, without your proposal.

And naming is an important issue: If you buy beef lasagne, you don't want to 
have horse meat in them! Likewise, if you install kdelibs4, you don't want 
to get kdelibs 3 installed.

> That's still not explaining. 2 is not "several".

With the security issue, I listed 3 reasons now. :-) There are certainly 
more, but those 3 are already severe enough to make your proposal a complete 
no go.

> And "I do not accept solution" is not the same as "there is no solution".

It's not that *I* don't accept your "solution", it's just that it doesn't 
work.

        Kevin Kofler