they should just bite the bullet. [LWN.net]

they should just bite the bullet.

Posted Feb 19, 2007 20:31 UTC (Mon) by eklitzke (subscriber, #36426)
In reply to: they should just bite the bullet. by drag
Parent article: Fedora 7 release delayed

There are a number of reasons why this would be extremely difficult, if not impossible. For one, the deb and rpm formats are not 100% compatible -- if translating between them was easy, the tools for doing this (e.g. alien) would suck less.

Other reasons not to move from rpm include things like SELinux. If you look at the spec files in Fedora CVS, a number of them have special build provisions for building SELinux packages. IIRC, you can put commands in a spec file that are only applied if you are running SELinux, for example. Nowadays _every_ package (at least in core) is expected to work in an SELinux environment, and RHEL/Fedora are really the only viable SELinux platforms exactly because they have an order of magnitude more experience and time invested in this issue. To move to deb would involve rewriting parts of the deb infrastructure.

Also, I hate to be partisan about this, but rpm really is a superior package format to deb. If you've done any kind of packaging, this is evident pretty much from the get go. The biggest problems with rpm have to do with rpmlib and not the rpm package format. Moving to deb would definitely be a step backwards, from a purely technical perspective.

Debian does have a lot more packages than Fedora. But a _lot_ of these are abandoned packages that haven't been updated in years and may not work, but just haven't been removed from the package tree (I believe this is Debian policy). If you don't include such packages in the count, and also omit non-free packages, my best guess is that Debian would only provide something like 10% more packages.

P.S. Fedora also includes man pages and documentation. The big difference with Debian is that they have a policy not to distribute anything without documentation, so a lot of the time Debian developers end up writing the man pages/documentation (although you will notice that there are still quite a few packages that are undocumented). For example, GNU does not provide a tar man page! The only one for GNU tar is the one written by Debian developers. Sometimes the Fedora devs don't pull in the Debian documentation, but it's hard to hold them too much at fault for that.

(Log in to post comments)

they should just bite the bullet.

Posted Feb 19, 2007 21:16 UTC (Mon) by drag (subscriber, #31333) [Link]

I don't think that Debian has a lot of abandoned packages. They ahve some, but most of that software is obsolete. You can see orphaned packages here:
http://www.debian.org/devel/wnpp/orphaned

And I've never ran into packages that don't work. Occasionally you get broken packages that would cause some sort of deadlock when figuring out dependancies, but that's something that happens in development branch and is temporary.

Plus as time goes by they've gotten better and better.

I understand that RPM is generally superior to Debs, but that is pretty much irrelevent to the end user's point of view. Seriously.

What makes or breaks a good package is quality control, consistancy between packages, documentation, and good itegration into the existing system. That's about it. It doesn't matter if it's portage or debs or rpm. The package format is incidental, almost to the point of irrelevency.

If it was the other way around I'd be saying the same things about Debian and Fedora.

The only thing that I am concerned about is that all of this software packaging nonsense is a duplication of effort on a massive scale.

The amount of manhours going into repackaging software, quality assurance testing, and everything involved is just enourmous.

It's not just making a distribution anymore. Debian and Fedora are creating a snapshot of all of the Free software aviable to anyone. Incompatable catalogs of not just the kernel and userland, but _EVERYTHING_.

Everything anywere that anybody could possibly want about anything. Every peice of software, every bit of code. Codified, rationalished, cross referenced, dependancies worked out. Everything.

It's not just 'distributions' anymore, it's 2 incompatable snapshots of the entire FOSS world. It's like having to build two egyption pyramids because the Pharaoh's wife can't figure out if she likes stones with rounded edges or stones with pointy edges.

Either way I just don't see it working out in the long run. Is Fedora people going to be perpetually scambling to compile and test packages for the rest of their lives while the Debian folks fail to get a distro out of the door on time from here and unto the end of time?

they should just bite the bullet.

Posted Feb 19, 2007 22:01 UTC (Mon) by bojan (subscriber, #14302) [Link]

> Is Fedora people going to be perpetually scambling to compile and test packages for the rest of their lives while the Debian folks fail to get a distro out of the door on time from here and unto the end of time?

Packages in Fedora change constantly and a random contributor may find that what used to build on Fedora X won't in the current development tree, because the organisation of packages and integration between them has been improved (well, changed at any rate :-). This is how the progress in made in Fedora - in small, incremental steps - Fedora releases.

But, and more importantly, this fast changing environment actually enables Red Hat folk and other Fedora contributors to experiment with the direction of the distribution rapidly.

> The only thing that I am concerned about is that all of this software packaging nonsense is a duplication of effort on a massive scale.

Yeah, it may look like that (I dreamed of a Grand Unified Linux Distro before :-), but it is also a good thing as it addresses different needs of different people. It also makes sure that upstream development is kept honest, as many different groups of people are attempting to bend the same software to do slightly different things.

Don't worry too much about people actually doing this. They either get paid to do it or want to do it. There is really no harm ;-)

they should just bite the bullet.

Posted Feb 20, 2007 0:44 UTC (Tue) by drag (subscriber, #31333) [Link]

Well I would actually considure Debian changes in small incremental steps.

If you track Debian Testing or Debian Sid then it's just constant upgrade of the system. Very rarely anything big breaks. It's been much much more kind to me tracking Debian Testing then trying to keep up with Fedora releases. I've done this successfully for years and never needed to reinstall.

In comaprision it's actually been difficult for me to keep up with Fedora releases. When I did keep up the majority of software that I used that wasn't part of Fedora Core wasn't aviable. Basicly ended up being that I couldn't upgrade to a new release of Fedora for the first 3 months or so.

Then again maybe things improved. The last time I tried Fedora was with FC4 and when I upgraded to that there was _no_ support for anything extra that I needed, even after I waited for a while. Maybe, hopefully, Fedora has finally figured out how to play well with others (ie third party repositories) and this including extras seems a step in the right direction.

But that's neither here nor there.

I suppose if they want to put all the extra work into just re-packaging software that's already been effectively packaged by other people then who am I to say they are wrong.

they should just bite the bullet.

Posted Feb 20, 2007 1:23 UTC (Tue) by bojan (subscriber, #14302) [Link]

> put all the extra work into just re-packaging software

Fedora releases are much more than that. As eklitzke pointed out in this discussion, SELinux integration is such an example. There are numerous other examples where a new release of Fedora featured major changes that would require you to upgrade every single package on the system anyway. And sometimes, doing so would render you system unusable if done by upgrading packages on the running system (e.g. switch to udev).

> In comaprision it's actually been difficult for me to keep up with Fedora releases.

I always have several machines with Fedora on them and it is true that each new release brings new "challenges" when upgrading (yes, I _always_ upgrade, never wipe clean, unless it's a new machine). But, that's what Fedora is all about - fast change. Obviously, not everyone's cup of tea, which is OK.

> Maybe, hopefully, Fedora has finally figured out how to play well with others (ie third party repositories) and this including extras seems a step in the right direction.

I think that Fedora isn't overly concerned with third party repositories (e.g. Livna, Fresh RPMS etc.). It is these repositories that need to adjust to the next release of Fedora, not the other way around. Usually, they do a pretty good job of doing that, since they also have a development repository, which is kept up to date with Rawhide (i.e. current Fedora developement tree).

Fedora change policy is similar to that of Linux kernel - changes happen all the time and are waiting for no one. You either fix your code to fit into the new way of doing things, or it won't work.

they should just bite the bullet.

Posted Feb 20, 2007 6:19 UTC (Tue) by drag (subscriber, #31333) [Link]

""Fedora releases are much more than that. As eklitzke pointed out in this discussion, SELinux integration is such an example. There are numerous other examples where a new release of Fedora featured major changes that would require you to upgrade every single package on the system anyway.""

I am not advocating binary compatability at all. At this time that is just a waste of time and effort.

I am not saying that Fedora should use debian's repositories.

I am saying that they should just leech as much as possible off of debian. Following the policies and practices and standards.

Finding a intellegent way to translate debian's deb-src packages and build system to RPM spec files. Which then can be used to build packages.

So match the orginization of the packages, match how the library versioning works. Match how they divide up the original tarballs into invidual packages and so on and so forth.

Binary and package for package compatability is a lost cause, IMO.

So you take how they are setup, translate that to spec files, use that to build the rpms, test it and add whatever you need to it and then your finished onto the next problem.

Then when you improve packages and do features then you make the patches public and Debian will take that and incorporate it back into their system. This is how it works, more or less, with the Debian-Ubuntu (and other debian based systems) relationship.

Then after a few releases of doing that then it may (or may not) make sense to do higher amounts of syncronization in terms of library versioning scemes and make cross-distribution dependencing tracking easier for developers and end users.

""I think that Fedora isn't overly concerned with third party repositories (e.g. Livna, Fresh RPMS etc.). It is these repositories that need to adjust to the next release of Fedora, not the other way around. Usually, they do a pretty good job of doing that, since they also have a development repository, which is kept up to date with Rawhide (i.e. current Fedora developement tree).

Fedora change policy is similar to that of Linux kernel - changes happen all the time and are waiting for no one. You either fix your code to fit into the new way of doing things, or it won't work.""

I guess so. I suppose then Fedora realy is just for developers and not for normal people.

they should just bite the bullet.

Posted Feb 20, 2007 8:23 UTC (Tue) by drag (subscriber, #31333) [Link]

btw I know this will probably never happen and I am not realy all that worried about it.

Leeching among distributions?

Posted Feb 27, 2007 13:49 UTC (Tue) by vonbrand (subscriber, #4458) [Link]

I am not saying that Fedora should use debian's repositories.
I am saying that they should just leech as much as possible off of debian. Following the policies and practices and standards.

Don't worry, they are leeching. Look at the changelogs for the Fedora packages, they often credit patches to Debian, and I'm sure it is the other way around too. Besides, Fedora's policy is to push for upstream changes where feasible, so everybody benefits.

Getting the packages from one system to build on the other is hard, getting them seamlessly integrated is much harder still. Yes, it is manual work. Stuff like Linux Standard Base help in creating some order among distributions, sure.

OTOH, Debian's performance WRT releases is dismal, to say the least... Fedora has managed to crank out 6 releases in a pretty short timeframe, mostly not too far from schedule. Debian should learn from Fedora here... so it is not that Debian's process is vastly superior either.

they should just bite the bullet.

Posted Feb 20, 2007 0:22 UTC (Tue) by ofeeley (subscriber, #36105) [Link]

"(although you will notice that there are still quite a few packages that are undocumented). For example, GNU does not provide a tar man page!"

No man page != no documentation. There's a perfectly good info page available. (And there's no point digressing into a disparagement of info -- it's documentation.)

Info pages

Posted Feb 20, 2007 2:01 UTC (Tue) by Ed_L. (guest, #24287) [Link]

Tar man pages vs. info is actually a pretty good example in favour of info. The tar documentation is extensive enough that a single man page would be about as wieldly as the single man page for bash.

Fortunately, bash and tar both have good info documentation.

Info pages

Posted Feb 20, 2007 14:09 UTC (Tue) by ofeeley (subscriber, #36105) [Link]

Oh, I agree completely. I love info. I find it much easier to use than man pages.

info schminfo

Posted Feb 22, 2007 7:13 UTC (Thu) by ldo (subscriber, #40946) [Link]

info is crap. Whatever won't fit into a man page, put into HTML. It's so much easier to read, navigate, search, publish on the Web etc.

info schminfo

Posted Feb 22, 2007 15:26 UTC (Thu) by nix (subscriber, #2304) [Link]

Your mileage definitely varies here. (e.g. how easy is it to regexp search a subtree of web pages? Essentially impossible without a lot of extra infrastructure, that's how easy.)

info schminfo

Posted Mar 1, 2007 3:53 UTC (Thu) by roelofs (subscriber, #2599) [Link]

Your mileage definitely varies here. (e.g. how easy is it to regexp search a subtree of web pages? Essentially impossible without a lot of extra infrastructure, that's how easy.)

But that's just extra UI fluff. (I'm not saying it's not useful UI fluff...) Is there any particularly good reason at this point why the underlying file format couldn't be HTML (or XHTML)? The info client could still behave as you like, including multi-page regex grep. Meanwhile, those of us who favor portability could use a standard web browser as the client.

Greg