Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Porting to the Linux Standard Base 41

An anonymous reader writes "If an application conforms to the Linux Standard Base (LSB), and a flavor of Linux is LSB compliant, the application is guaranteed to run. This tutorial, written by Martin Streicher, Editor in Chief of Linux Magazine, ensures that your code runs reliably on as many Linux flavors as possible. It shows you how to port your apps to the Linux Standard Base, then takes you through the LSB test tools to verify conformance."
This discussion has been archived. No new comments can be posted.

Porting to the Linux Standard Base

Comments Filter:
  • by Anonymous Coward on Thursday July 20, 2006 @11:24AM (#15750086)
    "If they were serious about a somewhat standard linux, they would have started with debian."

    1-LSB is more than just RPM.

    2-There's nothing wrong with RPM. Just the people who use it.
  • by 0racle ( 667029 ) on Thursday July 20, 2006 @11:39AM (#15750217)
    No, if they were serious they would have made it distro and packaging tool agnostic. Picking to base it on debs and the way Debian does things would be no different then picking rpm and how Red Hat does things.
  • by tlhIngan ( 30335 ) <[ten.frow] [ta] [todhsals]> on Thursday July 20, 2006 @11:42AM (#15750242)
    and was just an attempt by redhat to push the subpar RPM package format. If they were serious about a somewhat standard linux, they would have started with debian.

    There is nothing wrong with the RPM format (I do prefer Debian, though - it's a more unix-y way of doing things). It's just that for a long time there was no centralized repository of RPM packages, so everything was a mishmash, and led you to dependency hell. Debian though, has a central repository and enforced the provision that all packages must have dependencies on things inside the repository to be accepted. It's not a format issue, it's a policy issue. E.g., I can't take my Debian installation, point it at Ubuntu's servers, then just do "apt-get update; apt-get dist-upgrade" and expect my system to migrate to Ubuntu. Most likely I'd be left with a half-functional mess. Is .deb broken because of this? I hope not!

    RedHat never enforced the policy nor maintained a central repository of packages. Debian has. And for a while, Debian had superior package management tools.

    In fact, I really preferred the old Familiar Linux IPK format - you only need gzip and tar (it was all tarballs) to hack through those packages rather than debian's usage of ar and tarballs.

    (And these days, with apt-rpm and yum, dependency issues have reduced significantly).
  • Re:Not required (Score:3, Insightful)

    by ardor ( 673957 ) on Thursday July 20, 2006 @01:26PM (#15751102)
    Rubbish.

    Autotools are the wrong solution, LSB is the right one. Autofoo is an awful build system (the nick "autohell" has its reasons, just see the results in google). They are horrible to use, the scripts are a nightmare to debug, and M4 is just plain from hell. SCons, CMake, Premake, Jam are better tools (btw, CMake has been created by autotools veterans and creators). The interest in better build systems is quite high, just look at the KDE guys (they moved everything from autofoo to CMake), or at Blender. Autotools may have been a good idea back then, but its time for some progress.
    Also, NO ONE ever uses autotools in Windows, there is just no reason to do that.

    CS is bad bad bad? Oh my. CS is THE ONLY WAY Linux is ever going to have serious games (is Doom3 OS? UT2004? NWN?) and if Adobe decides to port Photoshop, be prepared for a binary blob. Maya is closed source. Baad programs we don't need? Dream on. Besides, the aforementioned games have their issues with incompatible libc's etc. which is the precise reason why LSB is a GOOD thing.
  • by Anonymous Coward on Thursday July 20, 2006 @02:13PM (#15751422)
    Binary installation should only be handled by priviliged users.

    Because source-based installation is pefectly safe, as we all read every line of code in the tarballs we ./configure && make && make install, right?

    Smartass.
  • by julesh ( 229690 ) on Thursday July 20, 2006 @02:20PM (#15751465)
    How much space can a statically linked program take? 10MB? 20MB? 30MB? everyone has 10GB of unused space nowadays...

    You do realise it also saves RAM as well, if the library is in use in multiple applications? Not everyone has 10GB free RAM. Or even 10MB free RAM.

    Besides: my current Linux system is running of a 3.3GB partition on my total 10GB hard disc. Not everyone runs current hardware, and many Linux users consider the fact that it is better at supporting old hardware than current versions of Windows one of its most important benefits.
  • by A nonymous Coward ( 7548 ) * on Thursday July 20, 2006 @02:46PM (#15751664)
    The point of dynamic libs is not just the memory savings, both RAM and disk, but the bug fixing. You fix a bug in a lib, all the linked apps get it fixed by definition. Static apps require the vendor to relink and rerelease the apps.

    There is also a small slowdown with dynamic apps, load and runtime, but that has never bothered me.

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Working...