Join or sign in Register for your free TechRepublic membership or if you are already a member, sign in using your preferred method below. Use Your Email Use FacebookUse Linkedin

Pros and Cons of using LSB compliant distro

Locked

Just noticed on perusing the standard that there are a few points that may make targeting lsb compliance a bad idea.

RPM REQUIRED
this means that any debian based system, using apt and .debs, as well as the from source distros will never be able to be compliant.

the big sticky point, in my opinion is the requirement of one system over any other.

add to this the fact that only debian woody and slakware meet the version requirements for lsb compliancy, yet they cannot be compliant because they don’t use rpm. the test suite for lsb compliancy fails it’s own tests when building it.

the only real pro for this standard is that, if you are developing software for commercial release, then targeting such a standard removes complexity in the installation of your application. you know what requirements will be on the system, and what you will need to include with the application to enable installation of it.

editing to add:

http://www.linuxbase.org/

Topic

I’ve had a lot of trouble with nonstandard config.

In reply to Pros and Cons of using LSB compliant distro

I can’t tell you how many open source projects I’ve failed to install because they wouldn’t compile without a lot of tweaking. That’s an area where I am weak so I just give up rather than try to tell the make utility what version of gcc I have or where to find libraries or whatever.

I’ve been using SuSE for several years. Recently I made a machine dual boot with SuSE and Debian. I’m finding the Debian to have its own set of challenges. In other words it doesn’t look like Debian is an answer to the problems with SuSE. I think that it is still worth learning Debian so I’m doing that now.

I’ve heard that even though Ubuntu is based on Debian it is restructured to the point that Debian packages don’t install on Ubuntu. I haven’t checked that out so don’t quote me.

Arggg!!! Standards? Where are they?

Learning different distos?

In reply to I’ve had a lot of trouble with nonstandard config.

I’m trying to expand my very limited Linux knowledge. I don’t understand what is meant by learning a particular distro, as when sj commented, “I think that it is still worth learning Debian…”.

Isn’t Linux, Linux? If I start with one distro, how much of what I learn can I expect to carry over when I load a different one? What are some of the activities that I can expect to have to relearn when I change distros?

These are the kind of questions that keep me from moving forward with my experimentation. I don’t want to start with one distro and find out I haven’t learned anything that will transfer. Some of the discussions make it sound like learning a new distro is comparable to learning an entire new OS.

yup

In reply to Learning different distos?

the kernel and base cli tools are the same.
it all fits onlo one cdrom, as a live cd, and only uses about 300 megs of it.*

the problem with going between distros, which the lsb tries to address, is the different versions of the same library and applications.
If I write an application on a 2.4 kernel box, with only kde 2.0 and gnome 1.3 and gcc 2.3.3, your box has the 2.6.8 kernel and has kde 3.3 and gnome 2.4 and gcc 3.4.2.
the differences can break the application for your box.

some distros are still using the 2.4 series kernels, others are bleeding edge 2.6 series. ( 2.8 series will be out fairly soon it seems )

then the different package management tools, apt-get for debian base, rpm for red hat based, tgz for slakware based and the tar.gz / tar.bz(2) of the sources only distros.
with an application coded for debian, released in .deb, slakware and red hat and source based distros will have a battle to get it installed.
the differences in the toolchains, as well as in where every file other than the base toolset is located.

Mandriva even changes the location of the menu files for the guis, so you have to edit the sources to add thier path, or edit thier menus after installing.

the other pain is the dependancy issue.
try installing gphpedit, you need a specific version of the gnome vfs library, gtkskintilla and a few other libs, most of which have thier own dependancies, and it all needs to be installed in a specific order. ( no, there is no list of what that order is, you have to fumble it out for yourself ) oh, what’s that, your distro has them all but not in the usuall place? then you have to tell the app, in the ./configure options where each and every one is installed to.

this is what he’s reffering to.
it’s also why a standard like the lsb is needed.

* with the sources for it all, but with also a compressed filesystem and specially patched kernel.

Thanks

In reply to yup

That clears up my confusion, although it’s a bit discouraging.

I can understand apps written on an older kernel not running on a newer one. That’s unfortunately no different from Windows.

I can understand different installation packages, but I don’t know why someone would develop a program and then not make it available across all package managers.

I’ve been mentally thinking of dependencies the same way I think of Windows “DLL Hell”, and so far the comparison has worked.

Again, thanks. Your original post is now much clearer to me, and I can see why you feel some standards are needed.

actually

In reply to Thanks

it’s not so much the differences in the kernel as in the coding for the application being set for only one version.
they use a structure of:
glibcver = 1.2 instead of glibcver >= 1.2
or, they built the app with gcc 3.2 and it won’t build on a system with 3.3 because they “required” 3.2 only.

the linux kernel versions tend to maintain a significant backwards compatability. thread process handles stay the same, even though the actual handling improved.
so the fork() exec () calls work for 2.4 and 2.6 series kernels.

it’s everything outsde of the kernel where the changes break compatability. 🙂
( don’t try using kde 3 on a 2.4 kernel system, if you have a 2.6 kernel system also. )

with multiple distros, and versions on your system you find breakages that are caused by different versions of user pace software. ( I had mandrake 8.2 as well as 10.0 on same partions structure, using same home directory. the changes made between the versions broke the 8.2 for anything other than console. the commercial app I need the 8.2 for broke when the xserver broke.

Don’t be discouraged

In reply to Learning different distos?

The differences between Linux distributions is very like the differences between Windows versions, as you speculated. All of the basic stuff is there somewhere. The variations aren’t all that bad. It mostly shows up when you try to install a software package that needs to be compiled from source code.

If you choose one of the popular distributions as your first you will be fine. Some like Red Hat, SuSE, and Mandriva, have advanced configuration tools to help you get your machine configured without a lot of pain. Debian, I have found, gives you a basic Linux environment and its apt/dselect tool. Otherwise is is just Linux. There’s nothing wrong with that it’s just that when you have installed Debian you have a very basic system. If you want a GUI you will have to install it after you finish installing Debian, which means that you will have to figure out how to install it, or anything else that you want. If you happen to have a need for a basic system with no frills then Debian will give you that. For instance I put Debian on another machine: AMD K6 366 MHz (like a Pentium II), 256 MB RAM, 9 GB disk. Debian easily fit on the disk with room to spare and runs very fast. It boots fast and runs fast.

I would recommend either Red Hat, SuSE, or Mandriva for your first Linux. They’re all good. They’re all popular. And there is enough in common between all Linux distros that learning one distro is fine for several years.

Yeah, it’s not so bad — we just like to complain.

In reply to Don’t be discouraged

Linux is Linux under the hood. There are two major sets of filesystem hierarchy, though: one is used by RPM-based distributions, because they model their filesystem hierarchies off Red Hat, and the other is used by “the rest”, and is a more traditional unixy approach to filesystem hierarchy (which means it’s simpler, cleaner, and easier to understand when browsing through it the old-fashioned way). There are also three different types of package formats: .rpm, .deb, and “everything else”. The .rpm packages tend to be very distro- and version-specific a lot of the time. The .deb packages are very portable between Debian-based distributions, as long as a given distribution hasn’t played silly buggers with things like filesystem hierarchy or with permissions handling (think: Ubuntu). Anything not using .rpm or .deb files is probably using something unique to that distro (or small family of distros). Often, a given package type is not compatible on a distro that uses a different package type by default. Often, software that is not very well configured doesn’t install properly on one distro when it was designed for another that has a different filesystem hierarchy.

When people complain, or in general discuss, “learning” a “new distro”, what they’re referring to mostly consists of the following:

dealing with the compatibility issues in using closed-source or half-baked software that was targeted for only one distro

dealing with differences in how package management is handled

dealing with the fact that sometimes you have to search a little harder to find where a particular configuration file might be hidden

Once you get familiar with two or three very different Linux distros, you’ll have an excellent grasp of how to find stuff even when you move to yet another very different distro because, though they’re very different from each other for Linux distros, they’re still more alike than two Windows releases (let alone the differences between Linux and Windows). When we who’ve used Linux a lot complain about the differences between distros and talk about learning a new one, we’re talking more about edge cases than core issues of moving from one distro to another.

Ultimately, the biggest difference you’ll see between distros will be the default window manager and the way the installer looks.

The new debian-installer does provide a means for installing a default GUI setup, by the way, so you don’t [b]necessarily[/b] have a lean install of almost no software. I do recommend doing a lean install and only installing software as you need it, using “apt-get install”, however. The apt system is the slickest, simplest, easiest package management system I’ve seen, and makes it not only possible but absurdly easy to start with a near “bare metal” install of Debian and build from there without any problems. It’s the “best” (in my opinion) way of getting exactly the system configuration you want, no more and no less.

I’m not a fan of the “install everything and figure that means you have what you want” methodology. I don’t need or want “everything”. I just need and want what I need and want, and I very much want to not have a bunch of unnecessary cruft. Thus, I’m a fan of Debian.

Not a huge fan of RPM either

In reply to Pros and Cons of using LSB compliant distro

I can’t remember what distro I was trying to set up (and since discarded) but the installer could handle some but not all RPM packages … I think it was like 20/80 success/failure.

Maybe it is just me …

it’s more

In reply to Not a huge fan of RPM either

like I don’t agree with the standard specifying which package management system than I don’t like rpm.

corrupt packages happen with all systems, when they have been transmitted over the ‘net. not all the time, but I’ve even gotten .tar.bz2 files that couldn’t be used.

RPM compliance

In reply to Not a huge fan of RPM either

The problem with rpms is that they can be build specific.

For instance a Mandriva (Mandrake) rpm may or may not work on a Red Hat/Fedora build. I HATE THAT! I hate it when things are build specific.

More and more I’m leaning towards Gentoo (the other Slack meat)

may or may not?

In reply to RPM compliance

mandriva builds i586 only
red hat builds i386
they should break at installation because of arcitechtural differences in the base executables and the other distro’s rpm

Debian is compliant

In reply to Pros and Cons of using LSB compliant distro

Debian includes RPM support. It’s just not preferred. In fact, I’m not sure Debian has RPM support for any reason other than simply LSB compliance.

Debian supports RPMs both by way of the Alien package translation system and directly. You kinda have to “break” the apt system to use RPMs, but you can do it.

As far as I’m aware, LSB compliance requires RPM support, not that it’s the primary package manager.

Of course, finding a Debian-compatible RPM is another matter entirely. RPM support on Debian is basically just an appendix: largely useless, but there just to conform to the standard.

I’m pretty annoyed with a couple stupid little tidbits like that in the LSB specification, but at least the specification exists.

Meanwhile, RHEL/Fedora isn’t LSB compliant either, because LSB compliance implies FHS compliance, and Red Hat has been screwing up its filesystem hierarchy for years. Its use of a nonstandard kernel sorta screws the pooch on LSB compliance, too.

i’ll take

In reply to Debian is compliant

your word that it means support for rpm in the spec.
i don’t agree with it going that far, since package management is, or should be, a user choice item.

in my opinion a standard is good, but with the number of options for pakage managment, including none for the from source distros, the number of options for bootloaders, they should stick with the fsh, and bare bones for the standard, not get into saying you need this tool or that tool.

the base should be the bare minimum to have a bootable, functional cli box.
everything else is optional, on an as needed / wanted basis.
an example:
file system hierarchy
kernel,
base toolchain
[ contents of /dev and /bin and /sbin, gcc, glibc ]
text editing tool
cli browser
network support

anything else is going to far, for a standard for all distros to meet.

same here

In reply to i’ll take

I’m rather strongly of the opinion that enforcing RPM support in the spec is about [b]stupid[/b], in all its glory. This is especially the case considering that:

1. There are more Debian-based distros that use .deb format packages as the standard package type than distros that use .rpm format for the standard package type.

2. The .deb format is older than the .rpm format.

3. The .deb format is better designed.

4. The APT system works better than the APT-RPM port, and APT is pretty unquestionably the best package management system out there, making tools like YUM and urpmi look like stinking feces in comparison. Well, okay, urpmi actually [b]is[/b] stinking feces, but still, APT makes YUM look bad.

Package management should not be in the standard, in any case. It’s something that’s going to evolve over time and continue to change. Mandating support for anything beyond source tarballs for software packaging is just stupid. Tools aren’t viable standards. So, yeah, we’re in agreement, regarding the stupidity of that choice in the LSB.

why not tar?

In reply to same here

My suggestion goes like this :
* Whatever be the application developed can now be given in the tar format only such that rpm and apt get tools can extract info from tarballs and place according to the File hierarchy of the distro standards.
* Since i’m involved in the preparation of the debian based distro and looking for the standards, i feel lot hitch in the lsb and if something goes by the standard it should not adapt a particular distro based package management tool which that itself is not generic for all the distros.

[Author]

Replies