Is Fedora a rolling distro

Today, looking at the output of my mirror script for my LUG's ftp repos, I found, like almost every two or three days, a very long list of updated packages in Fedora's updates repos. This wasn't new, and actually I already knew that normally their updates' repos are bigger that the distros' ones. Here you can see what I mean:

$ du -sm fedora/12/Fedora/i386/os/Packages/ fedora/updates/12/i386/
2853    fedora/12/Fedora/i386/os/Packages/
7764    fedora/updates/12/i386/

More that two times the size! What's going on here? To answer that one has to get the package names from one repo and the other and compare. The easiest way I got was to use the filenames, but in contrast to .deb based distros, which separate package name, version and architecture by _, .rpm based distros (such as, of course, Fedora), they use -, which can also occur in the middle of the package name. So I hacked a oneliner that approximates what I wanted:

ls -1 fedora/12/Fedora/i386/os/Packages/*.rpm | python -c 'import sys; \
    lines= sys.stdin.readlines (); \
    lines.sort();\
    packs_ver= [ "-".join ( x.split (".")[0].split ("-")[:-1] ) \
        for x in lines ]; \
    print "\n".join (packs_ver)'

Putting both outputs in spearate files and using diff -y --left-column one can get some rough numbers:

# how many are in each side?
$ wc -l fc12*
  2399 fc12.list
  5299 fc12-up.list

# these packages have not been updated
$ diff -y --left-column fc12* | grep '<' | wc -l
485

# these lines are different, so adds one package on each side
$ diff -y --left-column fc12* | grep '|' | wc -l
887

# there are new packages
$ diff -y --left-column fc12* | grep '>' | wc -l
3385

# these are common, so they have been updated
$ diff -y --left-column fc12* | grep '(' | wc -l
1027

So the fisrt clue that I'm right: Fedora adds packages (3385+887) to the original distro (2399) via the updates; that is, it grows with time. One notable remark is that this happens with every 'release', as if they start from scratch (or a small base) for each release. Also, half of the original packages (1027) have been updated, while the rest (485+887) have not. So in total FC12 started with 2.4k packages last November, and in only 4 months 1k of its packages has been updtated at least once (but I know that the common case has had more than just only one) and 4.2k additions, adding up to roughly 6.6k packages so far. Also, and this is also an important fact, there are between 20 and 170 updates per day (at least that's the numbers that came up looking at this week's logs).

I know that Fedora is mostly a development distro (in the sense that is in constant development, not that it is aimed for developers, at least not for mere mortals-among-developers like me), so it only makes sense that there are so many updates, but why bothering making a release?

The answer lies, I think, in the notable remark I mention up there. Fedora starts almost from scratch everytime; that's why they can introduce so many and so big system changes from one release to the next. SELinux and PulseAudio are the two I can remember without checking the interwebs. Probably because it has so fresh and sometimes so radical changes is that core developers use it. Maybe one could call it the ultimate (b)leading edge distro, shy of LFS and probably closely followed by Gentoo.

So my conclusion is right now Fedora is not for me anymore. Maybe some 8 years ago, when I had time to fiddle with the system, but now I prefer to trust a more stable (but not completely, mind you) Debian Sid. With only 6k+ packages in their official repos one could also say that it is small compared with the ~28k packages in Debian Sid, but their packaging policies differ a lot to make a one to one comparisson1 (nonetheless, I think that there is more soft in Debian that in the official Fedora). What does puzzle me is why a noticeable part of the sysadmins I know prefer to run it in their servers. Maybe I should ask them :)


  1. Debian, for instance, breaks library packages in three: the library, the development files (headers, static versions) and optionally a debug version, with symbol info for useful stack traces. There are more examples.