Linux Standard Base 1.1

Staili writes: "Zdnet is reporting that The Free Standards Group released version 1.1 of the Linux Standard Base (LSB) as well as the first version of the Linux Internationalization Initiative standard to deal with Linux language barriers."

Comments

Wired Article

[L-Wave]

Here[wired.com] is an article on wired that i had jsut submitted before I saw this go up...its pretty good, lists some big players. =)

Package format

[d-rock]

How much does standardizing on RPM as the package format affect systems like Debian? From my understanding the whole apt (.deb) system has a lot of nice features that RPM doesn't... Not that it's a bad thing, I just wonder how much debate went into this particular aspect.

Derek

Re:Package format

[Cpyder]

Both package formats have their (dis)advantages. Standardizing on RPM does not mean you can't get the advantages of apt, however: Apt has been adapted for RPM. It's used in Connectiva. More on apt-rpm at this site, or at a search engine near you. I hope that with the wider adoption of LSB and FHS standards it will be easier for both users and programmers to use "cross-distro" packages. Nowadays too many packages are wrongly linked to libraries, making them hard to use on other distros than the ones they were made for. Try to install a SuSE package on a RedHat system and you'll know what I'm talking about.

Re:Package format

[Alan]

IIRC .deb doesn't have some of the nice error checking that rpm has, like signing. Also compare files on a system to the originals in an .deb to check for tainted files (though while looking I see that debsums(1) might do the trick.

Other problems is the PITA it is to do an non-interactive install of debs. One of the biggest bitches I hear about debian is that when doing an initial install, and you've gotten to the part where packages are installing it goes something like this:

*install*
*install*
*install*
*ask question via debconf*
*install*
*install*
*ask another question*
*install*
*install*
*install*
*ask same question again*
*install*
*install*
etc...

Also .deb's inadequate logging is mentioned, as well as keeping the install messages somewhere, or keeping previous versions of a package (what happens when you find out that libfoo is completely b0rked in the latest version, and have to run around searching for a mirror site that hasn't been updated yet. This generally only happens in unstable, but it's still a PITA :)

There were a couple of other features that .deb didn't have, but I don't recall them right now.

Some references and info is here though that's a lot more pro-deb than discussing this exact issue, but there's good info there.

Oh, and before you start flaming, I'm a long time debian user :)

LSB is about deployment

[dybdahl]

A Linux distribution can consist of 90% software not covered by the LSB. Therefore, it makes no sense to discuss "administering an LSB system".

LSB is about minimum requirements for a distribution in order to make distributions more compatible, i.e. it's about deployment. If you distribution is LSB 1.1 compliant, then you should be able to install all software that only requires LSB 1.1. compliance. For a start, this will not cover ordinary GUI software.

In order to create a long-lasting standard, you cannot cover issues that are constantly changing or under development, so don't expect LSB to cover a whole distribution anytime soon. But LSB is an important step to make sure that distributions don't fork into something incompatible.

Re:posix?

[bourne]

isn't this the whole idea of "posix compatible"?

I'm no expert, but I believe that POSIX compatibility only involves things like system calls and library interfaces. LSB includes things like filesystem layout and recommended locations, so that (for example) you don't have /usr/bin/sendmail on one distribution but /usr/sbin/sendmail on another distribution.

POSIX is an OS standard, LSB is a distribution standard.

Re:posix?

[The G]

POSIX is a documentation of minimal standards for the things we all take for granted in UNIX and UNIX-like systems. Things like "time is represented as seconds since the epoch" and "regular expressions are available through the regcomp() function, which returns an opque object to be passed to regexec()" and "all POSIX systems will provide threads, mutexes, etc. that meet the following interface, in addition to whatever platform-specific threading they may have."

Linux is almost, but not quite, POSIX compliant -- I don't recall why it isn't, but in practice you're unlikely to run across the boundary cases.

POSIX, however, does not speicify things like the difference between /bin, /sbin, /usr/sbin, etc. It provides only a fairly minimal set of tool requirements (for instance, .tar files aren't guaranteed to be cross-platform compatible, iirc).

This is the hole that the LSB is trying to address -- creating a standard that actually provides real consistancy not only to programmers but to users.
--G

LSB 1.1....great....now someone...

[Chanc_Gorkon]

ANYONE start using it! Preferably everyone.

Some people will say well what does this does to debian/apt. I say nothing. Apt is not dependant on using deb as evidenced by apt-rpm. Debian can adapt the Connectiva apt-rpm package and switch to rpm's rather easily (unless they are too pig headed). Also, does LSB compliance not allow you to use other packages as well as accepting RPM's?? That way debian can stick to debs for the short term, and switch to RPM's in the long term. Then at some point in the future, LSB can change the spec and require RPM only.

I would also like to see apt or some advanced package manager included in the spec as well. Apt kicks major booty and takes away the dependency hunt.

Mandrake

[xanadu-xtroot.com]

I almost hate to do this but, I think Mandrake REALLY needs to start reading this and taking it into account. I've been using MDK for a few years now and I do really like the distro. Hell, infact, I'm burring the 8.2 beta2 right now. *BUT* one thing that makes me REALLY hate what they do is all this -mdk crap. Even something simply like the Kicker Menu icons are all stored in -mdk locations so no source that you use will get the icons right without you making symlins all over the place. And even when you DO make all the symlinks and copy stuff to MDK's locations, next time you install something, their RPM's will run "update-menus" and "fix" all their locations to their liking. THAT makes me not too happy.

For instance Mosfet's Liquid theme. He has a kcontrol module that he uses to control his theme. You can't have it on MDK if you don't copy his module to (something like, I forget): /usrshare/applnk-mdk-simplified/.hidden/Configurat ion. Not the two big problems there. First eh mkd specifck location and then a HIDDEN dir on top of that.

It's this sort of thing that (my understand is) the LSB is supposed to help "prevent". I wish MDK would follow it. I think it would REALLY help the newbies if they did.

Re:What is the point of this?

[Diabolical]

The LSB tries to standardize something completely different then POSIX does. It tries to standardize the minmum aspect that a distro must have to be compatible with others. Like mentioned in an earlier post, try to install a SuSE RPM on a RedHat system to see what the LSB means and tries to standardize.

POSIX is more on a programmers level where LSB and the FHS are more on the disk layout and library standardization.

For example: If i have a program for Linux it needs to use some libraries. There are different kind of these with every distro.. which library to include/use.. What is the disk layout? Do i install my package in /opt or in /usr/whatever. These problems are difficult to tackle when you write a linux program. If FSB and FHS are widely used and are really a standard one wouldn't have to worry about these trivial things..

Those who read the standards might have a clue

[Christopher B. Brown]

Debian packages do not HAVE TO BE .RPM.

If you were to actually read the standards document, the requirement is:

Distributions must provide a mechanism for installing applications in this packaging format with some restrictions listed below. [2]

And if you were to look for note [2] you would find that it reads:

[2] The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages.

The point of LSB is to allow third party applications to be portable across distributions. That does not mandate anything about how a distribution chooses to package the Linux kernel, GLIBC, or much of anything else that it itself chooses to package.

Indeed, nothing mandates that an LSB-compliant distribution even has its own packaging scheme. A distribution could have all the components required by LSB in all the right spots, and just plain put them there. No "packages;" just files.