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.

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.