Why I'm using Fedora [LWN.net]

Why I'm using Fedora

Posted May 5, 2004 19:03 UTC (Wed) by brouhaha (subscriber, #1698)
In reply to: Revealed: how Fedora and the community interact by maceto
Parent article: Revealed: how Fedora and the community interact

I can`t understand why people use it?

Because I ran RHL before, and upgrading to Fedora Core 1 was trivial. Switching to Debian, SuSE, or Mandrake would be a lot more work.

I've been keeping an eye on Debian, as I'm a big fan of their hard line stance on freedom, but their stable distribution is ridiculously out of date, and the last time my friend Mike and I tried to install it, we got fed up with the obscure and complicated questions the installer asked. Mike and I each have more than twenty years of Unix experience, but some of the questions stumped both of us.

I'm told the new Debian installer is much better, so someday when Sarge is released I'll give it a try.

On the other hand, I'm quite interested in SEL, and it appears that Fedora Core 2 will be the first major distribution to support it.

Most people seem to think that dpkg is much better than RPM, but as a software developer I disagree. It appears to me that a dpkg can contain exactly one source tarball and exactly one patch. That means that if I want to package up something with multiple patches, I have to mash the patches all together. Then when a new base release of the software I'm packaging needs only a subset of the original patches, and a few new ones, it's a royal pain to repackage it. Plus, that makes it much harder for someone else to take my dpkg and build a new one with a different set of patches. RPM seems like a clear winner here. Of course, most users aren't concerned with building patches, and Debian used to have an advantage for the user with apt, but now the same capabilities are available in Fedora with either yum or apt.

(Log in to post comments)

Why I'm using Fedora

Posted May 6, 2004 12:51 UTC (Thu) by pizza (subscriber, #46) [Link]

I'm not sure what debhelper does (help automate package construction?), but there is an 'rpmlint' that at least catches the aggregious errors in your .spec files.

The concept behind SRPMs is that it is entierely self-contained; everything that goes into the final package is found inside the SRPM; no external files (save the build dependencies) are needed. And SRPMs can include an effectilvely arbitrary number of individial "source" and "patch" files.

Your version control problem sounds more like an artifact of how you create and maintain packages rather than anything inherent to the packaging format; after all keeping old version of .dpkgs wholly intact is going to create much the same repository scope as .[s]rpms, eh?

Debian's advantages over everything else stem from three things -- policy, policy, policy. From a technical aspect (eg dpkg vs rpm) however, things are pretty much level, with strengths and weaknesses stemming from the slated goals of the distribution.

I personally use RH/FC because I have to do the least amount of work to get the system set up and running how I like -- and the majority of said work is always working around the boneheaded policies of the distro. So naturally I chose the distro whose inherent boneheadedness maps the closest to mine.

Why I'm using Fedora

Posted May 6, 2004 13:50 UTC (Thu) by angdraug (subscriber, #7487) [Link]

I'm not sure what debhelper does (help automate package construction?)

Yes. Automates tens of different package construction tasks, from manpage installation to X font registration or calculation of Perl dependencies.

The concept behind SRPMs is that it is entierely self-contained; everything that goes into the final package is found inside the SRPM; no external files (save the build dependencies) are needed. And SRPMs can include an effectilvely arbitrary number of individial "source" and "patch" files.

Same applies to a Debian source package: debianization patch can include arbitrary number of individual source and patch files. The only difference is that instead of one file you have a pair of files, which is, once again, entirely self-contained.

Your version control problem sounds more like an artifact of how you create and maintain packages rather than anything inherent to the packaging format; after all keeping old version of .dpkgs wholly intact is going to create much the same repository scope as .[s]rpms, eh?

Please, do your homework before making comments like this one, it exposes that you didn't actually take a look at the Debian packaging system, as I've suggested in my previous comment. Or else you would have at least noticed that binary packages in Debian have .deb extension ;-)

As to our version control problem, we don't need to keep old versions of binary packages, we can reconstruct them from source packages anytime, given that we still keep the latter around. From the other hand, we can't just put the whole damn Linux distro into SCM, it's even more disk space and we only want to maintain a small part of it ourselves.

Why I'm using Fedora

Posted May 6, 2004 22:22 UTC (Thu) by mattdm (subscriber, #18) [Link]

It appears wrong, you have to take a closer look. It all depends on how you organize things inside that single patch, there are several script systems of varying complexity that help you to organize your patches, see for example source packages for xfree86 or mutt.

That's okay if the package was arranged that way to start, but it's hard to take some _other_ package and add this to it. You have to reorganize the whole thing. And then if there's an upstream update, you have to go through the whole process again. With RPM, there's no external scripting systems of _any_ complexity required for this basic functionality.

And don't underestimate the advantage of storing source tarball and packaging patches in two separate files.

Okay. Meanwhile, don't underestimate the advantage of storing everything in one archive. There's no question that the collection of source files and patches and control file match and are the ones used to build the binaries you've got.

When you have to keep old versions of your packages around for version control, speed of growths of repository with rpms quickly becomes prohibitive to the whole affair [...]

How many versions of your packages do you have? Is this your own code you're packaging up? In that case, I recommend not making the final distribution package format your source code management tool -- use CVS or one of the newer things, and keep your spec file with your source code. If it's other people's stuff you're packaging, how many versions, do you realistically have? It's not like disk space costs much these days!

Why I'm using Fedora

Posted May 7, 2004 10:11 UTC (Fri) by angdraug (subscriber, #7487) [Link]

That's okay if the package was arranged that way to start, but it's hard to take some _other_ package and add this to it.

If you deal with bad packaging, more often than not you have to rework it anyway, but it only has to be done once.

And then if there's an upstream update, you have to go through the whole process again.

Err, now I lost you. Is your upstream a someone else's source rpm of some software, or original tarball of the software? In the former case, what for? In the latter, I don't see why the packaging, once done properly, needs to be redone from scratch for each new upstream version, and how is it different for rpm and dpkg?

With RPM, there's no external scripting systems of _any_ complexity required for this basic functionality.

Right, and there is one single internal scripting system which you have no choice but to love and live with.

I think we are rapidly moving towards the ground of personal preferences with this argument. My point wasn't to say that dpkg is better, it was to refute this claim: "RPM seems like a clear winner here". I can see advantages of both, and I aknowledge that by knowing dpkg better I also know its advantages better.

Meanwhile, don't underestimate the advantage of storing everything in one archive.

I'm afraid I still underestimate it: I utterly fail to see the difference in complexity between 1 and 2. Between 1 and n, yes, but not 2, it is still a single entity in my perception. To claim otherwise is the same as to claim that unpacking the source tarball into a directory with 1000 files somehow splits the entity of the package into 1000 entities, vs. merely changing the physical layout of the same entity.

How many versions of your packages do you have? Is this your own code you're packaging up? In that case, I recommend not making the final distribution package format your source code management tool -- use CVS or one of the newer things, and keep your spec file with your source code. If it's other people's stuff you're packaging, how many versions, do you realistically have? It's not like disk space costs much these days!

It is both our code and other people's stuff. For our code, we already keep it in CVS, and can track its history just fine (we're looking at "newer things" too, but that's another story). Our problem is with the other people's stuff, which also changes over time, and we would like to have a much more fine-grained history of that.

At the moment, we freeze the external repository for each release branch of our software, and we have tens of these, so we're still ok storage-wise until this number grows to hundreds (single version of repository is at 10GB and growing, and we need to set aside quite some space for developers' build chroots, and we can't afford fast and reliable multi-terabyte array), but we have a problem when we have to update some external library to fix a bug in a 2-years old release, and then reproduce the build that was made before this update. It doesn't help much if we have a fine-grained version control of our own software, but are unable to reproduce the environment against which some old version of our software operated.

As I've said, we're fine so far, but we're only one order of magnitude away from hitting the storage limit, and that may happen if we were to fork our repository for several lines of products or for different architectures.