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.