Why Linux Appears Fragmented:

[energyman]

And nobody cares about that part of the LSB. Doesn't really solve anything, does it? The question may have been answered by someone, but no action was taken. Ubuntu has the market share to actually force the decision.

LSB is currently like XHTML. The biggest player doesn't care about it. The W3C learned that they had to listen to the actual parties involved to create a standard that everybody wants to implement. The most important thing about HTML 5 is specifying Internet Explorer's actual behaviour. The most important thing about the LSB will also have to be specifying actual behaviour.

ubuntu is completely irrelevant in that regard.

RHEL and SLED/SLES are the important distros out there. They use rpm. Problem solved. It is not their fault that ubuntu sucks.

[Svartalf]

That's why this cadence plan of Mark Shuttleworth is so important. And that's something the LSB should specify, too: an annual or biannual release of the LSB which specifies which versions of packages have to be supported. Other versions can be provided as well, but the LSB specifies a baseline.

It's specifying too LARGE of a baseline. It's monolithic where it needs to be in chunks. Basline verss server versus desktop profile- with it being snap-together so that if you wanted both server and desktop (WHY?) you could easily expect it to all work. As it currently stands, it's useless to anyone other than pretty much Red Hat, CentOS, MontaVista, etc. (And it's not overly useful there...I can assure you of that. I had Pigeon Point hand me something LSB compliant and it wouldn't at all run on a MontaVista CGE 5.1 system to save it's life.)

If they'd done that and then followed what Shuttleworth's proposing, it might've gone somewhere quicker.

[Remco]

Packaging is the least of your concerns and all LSB really does is insist upon a packaging and a place to put things- and provides what MIGHT be the right mix for your application upon install.

That's why this cadence plan of Mark Shuttleworth is so important. And that's something the LSB should specify, too: an annual or biannual release of the LSB which specifies which versions of packages have to be supported. Other versions can be provided as well, but the LSB specifies a baseline.

[Svartalf]

Actually iirc Linux Standard Base agreed on using RPM as the de facto package type, this just made Debianists scream so loudly that DEB was added too although RPM is still primary package type. Then again, LSB seems to have died off too.

Unfortunately, LSB didn't fix any of the REAL problems that a proprietary developer would face shipping binaries to a large suite of people.

All it did was insure that you had a defined packaging format, a defined directory structure and explicit places for binary and config files, and a rigidly defined minimum set of .so's and command binaries that one could expect to be on the system if it was in an LSB compliant configuration. In and of itself, that sort-of/sort-of-not helps a developer. For starters, someone could be trimming their system down- LSB makes a system configuration HUGE. Carrier Grade Linux could be VASTLY smaller if it weren't for the braindead mass LSB presents- because there's no subsets of things. It's all LSB or not. And that doesn't get into the fact that LSB wasn't designed with an end-user in mind, though it mostly worked out that way- it was intended for server stuff.

Now, you've got this whole lot. After dragging all sorts of crap you don't need and the server world does (and vice-versa after a fashion...) you'd think that you'd be able to ship binaries to more than Red Hat, SuSE, and so forth, right? WRONG. An LSB compliant RPM MIGHT work out well, might not. What's the problem? Well...as an example, you might have libpng on there, but instead of 1.2, they have 1.4 on there (heh...)- and your binary is looking for or linked against 1.2. Your binary will FAIL at that point. So, they make binaries against each of the LSB compliant distributions or make a single one and cross their fingers- or they do the additional steps of doing what we've done with Caster or similar stuff to ensure the binary works.

Packaging is the least of your concerns and all LSB really does is insist upon a packaging and a place to put things- and provides what MIGHT be the right mix for your application upon install.

[Remco]

The question 'which format to use' was answered many years ago.

Read the LSB.

It is rpm.

And nobody cares about that part of the LSB. Doesn't really solve anything, does it? The question may have been answered by someone, but no action was taken. Ubuntu has the market share to actually force the decision.

LSB is currently like XHTML. The biggest player doesn't care about it. The W3C learned that they had to listen to the actual parties involved to create a standard that everybody wants to implement. The most important thing about HTML 5 is specifying Internet Explorer's actual behaviour. The most important thing about the LSB will also have to be specifying actual behaviour.

[Svartalf]

He's a smart man. The last thing Ubuntu could use is more friction between Ubuntu and the rest of the Linux community.

Heh... There's wisdom there in his remark- and you caught it as did I.

[energyman]

The question 'which format to use' was answered many years ago.

Read the LSB.

It is rpm.

[pingufunkybeat]

Bring us teh heretic's head!!!!! >

[nanonyme]

I DO agree that we should finally settle on a package format. Deb and RPM are the two obvious choices, but which?

Better not walk down any dark street if Gentoo users live nearby with that kind of opionions. :3

[benmoran]

You know, I use and love Ubuntu, but I don't give a rats ass about deb in particular. I've use RPM based distros as well, and they work equally as good.

I DO agree that we should finally settle on a package format. Deb and RPM are the two obvious choices, but which? Is it utterly impossible for a package manager to support both? I never looked into it, but people always hype on how similar they are. Why not?

As far as I see it, things should be available in two ways. A package: deb/rpm/etc, and in source form. Of course, this requires the whole community to agree on one package system for it to work out, so as not to exclude anyone. Packages are a much better way than dealing with separate tar files containing binaries. If you want more controll over where the files go and whatnot, thats when I compile from source anyway.


Just some random thoughts.