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."

Wired Article

[L-Wave]

Here [wired.com][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. =)

Re:Distros are in but...

[jamesidm]

they both give it their 'virtual blessing' accroding to an article on the register [theregister.co.uk]

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: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 [connectiva.com]. More on apt-rpm at this site [sourceforge.net], or at a search engine near you. [google.com] 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:would be great

[staili]

Go to LSB's [linuxbase.org] website and you can see the Contributors. If they all follow it it'll be a standard.

Re:Distros are in but...

[the_2nd_coming]

you don't get it.........the structure of how the distro is layed out is not based on code (other than that of the installer) it is based on where the distrobution creaters what to put stuf, and how they want to link things, and how they want the directories layed out.....it is the structural placment of the programs......code is darwinian, but you need to have certain aspects remain the same.......the lattest stable glib, the latest stable KDE/Gnome, etc.....that is all...this will just put all the distrobutions at the same base at the same time......and the LSB will update as frequently as needed when a new stable library comes out.....

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

Re:Wow

[GauteL]

They do NOT standardize on GNOME. GNOME is mentioned ONE time in the entire LSB-document, and that is as an example for a packagename ("lsb-gnome-gnumeric").

They DO however standardize on RPM, which is fine, because almost all distributions use it. Debian probably only have to make sure they support RPMs as well as debs, something they already do through "alien". RPM is also in the Debian-repository.

Implies not much about ".deb"

[Christopher B. Brown]

The notion that switching to rpms would be "rather easy" demonstrates considerable ignorance.

There is a sizable set of tools used in the construction of Debian that are tightly tied to .deb packages.

apt is only the start of the "advanced" aspect of package management; what's far more critical are the set of development tools, like lintian, debscripts, jablicator, deb-make, deb-helper, equivs, dpkg-dev, apt-move, and such.

Eliminating all of that would be like telling the Linux kernel developers that they have to stop using C, and write Linux in assembly language.

It's not simply apt-get that "eliminates the dependancy hunt;": in order for the set of packages to be kept coherent, so they're not merely a jumble of RPMs of dubious provenance strewn across the Internet, you need the development tools.

To move Debian to RPMs would require rewriting all those tools for RPM use. There's merit to such an idea; if there were coherent tools for dealing with the development of a complete RPM-based distribution, you'd doubtless get better stability. But that's a big task, and your non-recognition of the issue doesn't make it go away...

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.

Read the standard.

[Christopher B. Brown]

Were you to read the standard, [linuxbase.org] you might be able to figure out answers to these and other meaningful questions.

The ans wer is, by the way, that it doesn't affect Debian in any meaningful way.

• The standard does not require that Debian drop its own packaging scheme.
• The standard does not mandate the use of RPM packaging within the distribution.

Read the standard; it's not particularly painful to read.

A much more entertaining thing is to think about how this might affect folks using FreeBSD [freebsd.org] It is entirely possible that this standard allows FreeBSD, which is conspicuously not Linux as well as not based on RPM packaging, to nonetheless become a nicely "compliant" Linux Standard Base platform.

Heck, Microsoft might be able to modify the "Unix Emulation" environment they have running on Windows NT (it's sold as something; I don't recall the name...) become compliant with LSB

This wouldn't be any stranger than when Microsoft made Windows NT a "POSIX" platform, or when IBM got OS/390 certified as a Branded Unix (tm)

The notion that this creates some massive problem for Debian is just plain ignorant, and when the article links to the publicly-available-on-the-web standard, being so ignorant is quite inexcuable.

The standard ISN'T about Linux

[Christopher B. Brown]

Look for the section entitled Kernel Requirements.

You won't find one. There isn't one.

This actually has a really entertaining implication, namely that despite saying "Linux" a lot, the standard hasn't anything forcibly to do with Linux.

• I'm fairly sure that the FreeBSD folks are likely to be able to take this standard and make some changes to conform their "Linux compatibility" subsystem with it.
• I'll bet that SCO (A division of Caldera) could take this standard and make SCO UNIX, with some layering of GLIBC, compatible with it.
• Ditto for BSDi, AIX, HP/UX, and Solaris. I'd almost bet anything Sun will do some work to get Solaris "conformant," at least looking ahead to Solaris/IA-64
• It would be quite the shock if Microsoft were to throw some effort into their "Linux Emulation Environment" (it exists; I don't recall the name...) to make it "LSB-Conformant."

The notion that this standard has much of anything to do with the Linux kernel is desparately ignorant of a reading of the standard.

Re:posix?

[Anonymous Coward]

Just adding to what you are saying -- POSIX is a US Government standard where some level of conformance is required to get certain contracts. That's why Windows NT has a useless minimal POSIX subsystem tacked on, and the Linux boot sequence has a "POSIX certification by so-n-so" message. There's different levels of the standard, so MS and Linux can get away with advertising some POSIX conformance.

As pointed out, POSIX is all about making it easy to port source code and has nothing to do with binary compatibility or runtime issues like paths and libraries.

POSIX is also part of a greater set of standards called the Single UNIX Specification (SUS). If you meet the SUS specs and pay a fee, you can advertise your product as "UNIX", even if it's entirely reverse engineered.

Have you read the standard?

[Christopher B. Brown]

Debian doesn't have to change package managers in order to comply with LSB.

For that matter, FreeBSD could comply with LSB without either:

• Using a Linux kernel

  Look at the standard; it specifies nothing about what OS kernel you are using.

• Using RPMs instead of pkgs and Ports

  Again, look at the standard. The set of package names to be managed by RPM, which runs on FreeBSD, is intentionally completely disjoint from any set of package names being managed "natively" by the distribution.

Careful reading of the standard shows that there is no requirement to be running Linux in order to conform with the standard. You could conceivably run some other kernel, like those from FreeBSD, NetBSD, Sun, SCO/Caldera. I'll bet it's at least theoretically possible that Windows NT with the "Unix emulation environment" could be made LSB-compliant.

Re:Package format

[Scott BaioWulf]

I'm pretty sure that .debs have error checking. FWICT apt checks md5sums to verify the package is intact and dpkg will verify the signature. I don't know for certain that it actually does this but thats what the man pages say.

The bugging questions is another issue. Personally I don't mind the questions. It IS possible however (as im sure your aware) to set the importance level of the questions. I don't know how many that could eliminate but it probably couldnt' be worse. dpkg probably also has a setting to always assume defaults.

/usr/local

[smcv]

That's exactly what /usr/local is for - locally compiled software. On most GNU and GNUish software the author sets it up to install to /usr/local by default, but you can do ./configure --prefix=/usr if you're building a distro package.

I don't know what other distros are like about this (I've only ever used Mandrake and Debian, and I didn't get experienced enough with Mandrake to know any of the internals), but Debian source packages come in two parts - a tarfile of original, unmodified source, plus a .diff.gz file containing the changes ("Debianizations") the Debian package maintaniner made to make it fit in with Debian conventions (moving all documentation to /usr/share/doc/name-of-the-package, for instance). If the original author's makefile or other code doesn't conform to Debian conventions, the maintainer will change it so it does.

For a program like you describe where (presumably) /usr/local/bin is hard-coded somewhere, the diff would include replacing that with /usr/bin - you, as an "upstream" developer, can probably make this easier by defining PREFIX to /usr/local and always referring to "$PREFIX/bin" and so on.