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:
  • LSB is worthless (Score:1, Flamebait)

    by Clockwurk ( 577966 ) *
    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.
    • by Anonymous Coward
      "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 )
      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.
      • No, if they were serious they would have made it distro and packaging tool agnostic.

        They chose to base it on a file archive with a header. It was a bit unlucky that they picked the .rpm suffix for it, but apart from that I don't see the problem. It's trivial to install LSB packages on Debian.

        The real problems with LSB lie elsewhere. I have never used an LSB compliant application and I run Linux >95% of the time.
      • No, if they were serious they would have made it distro and packaging tool agnostic.

        If they did that, what would an LSB-compliant system have to look like? It would completely defeat the purpose of having the standard in the first place.

    • RedHat were somewhat a latecomer to the LSB group. The aim of LSB is admirable but probably fatally flawed as the first poster shows it all in his mention that Debian should have been used as its basis.
      The aim (I might be wrong here) was to be totally distro independant but make all the key bits be in the same place especially in /etc and a few other key directories.

    • by tlhIngan ( 30335 ) <slashdot.worf@net> 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).
      • Talking about packaging mechanism I preffer the way closed source companies do things (like for example Google Picasa or Earth). This is, to link everything statically. Why not? That will warranty your application performance not mattering the libx.y.z.so the user has on its system.

        How much space can a statically linked program take? 10MB? 20MB? 30MB? everyone has 10GB of unused space nowadays...
        At least there should be that option, I will use it in order to avoid the hassle of having to download dependenci
        • Re:LSB is worthless (Score:3, Informative)

          by grimwell ( 141031 )
          Just now I am writing this from my university PC with Fedora, I do not have root access hence I can not install and run any new software. If I want to run something new I need to download the tarball and compile it, provided that the required libraries (with the required version) are isntalled, otherwise I am screwed. That is a flaw!

          Not a flaw, basic sysadmin'ing... don't want to users fucking things up.

          With the --prefix and --root switches for rpm, you can install software&libraries in your home direct
          • The downside with statically link executables is if there is a flaw(e.g. buffer overflow) with a library, you need to recompile&reinstall all the executables that have that library statically linked. Dynamically linked means just need to re-compile the offending library and restart the executable.

            For which you will update your application to the newest version containing already the patch uh? nothing too different to what happens now (for example firefox 1.0.0 ~ 1.5 updates). This would be achieved eith
            • For which you will update your application to the newest version containing already the patch uh?

              Yes, you're right. Go forth and spread your vision far&wide, so that the unwashed masses might be enlightened.
        • by julesh ( 229690 )
          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
        • 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.
        • A statically-linked program doesn't just use up more space on disk. It also uses more space in RAM. And caches.
        • How much space can a statically linked program take? 10MB? 20MB? 30MB? everyone has 10GB of unused space nowadays...

          You say that now, but just wait until you try to statically link each and every KDE or GNOME app with 50 MB worth of libraries. I could easily see that taking up (50 MB * 500 programs =) 25 GIGABYTES worth of disk space.

      • Actually you probably can dist-upgrade Debian to Ubuntu. This is not a task for a novice and is definetly not supported, but it should work.

        Its slighty more involved than "vim /etc/apt/sources.list;apt-get update;apt-get dist-upgrade" though.
    • Hoho, LSB is to make Linux more attractive to business. do you know how many enterprises/goverments I've seen using Debian in the last 8 years, zero.
      • Funny you should say that. I got this from a Debian mailing list today:

        Dzongkha Version of Debian GNU/Linux 3.1 launched

        The Information and Communication minister of the Royal Government of
        Bhutan, Lyonpo Leki Dorji, launched "DzongkhaLinux", an entirely
        localised GNU/Linux distribution based on Debian GNU/Linux 3.1. This
        is the first operating system that fully supports the country's
        national language and which has been developed in Bhutan.

        The Bhutan Department of Information Technology chose Debi

        • that's great news, and I don't say that Debian or derived works are unsuitable for business, just that I've not seen it as choice in U.S. for business. Now if someday most of the world's population standardizes on a distro by virtual of India and China and South America's and surrounding countries going in a different direction, maybe then the U.S. would have to change just to do business.
    • Re:LSB is worthless (Score:2, Informative)

      by int19h ( 156487 )
      Debian (and Ubuntu) have several lsb-packages that provides LSB-support (although the description of the package clearly states that the presence of the package should not be interpreted as a sign of full compliance (in similar (but different) wording)). Debian is also on the "team" behind the evolving LSB-standard (see freedesktop.org or search the web).

      I think LSB is great. For instance, people can write OpenGL-software and target lsb-graphics; instant portability.

      And, most important of all, if you're eve
  • by xxxJonBoyxxx ( 565205 ) on Thursday July 20, 2006 @11:27AM (#15750124)
    If you want to certify your application, download and read the Application Product Standard associated with your target hardware platform.
    ...but if you click that link, you are prompted for authentication information. Anyone have a "public" version of this doc?
  • Why use LSB? (Score:3, Informative)

    by dhasenan ( 758719 ) on Thursday July 20, 2006 @01:43PM (#15751211)
    There are three distributions listed that conform to LSB3.0: SUSE, RedHat, and Asianux. Why should I write for LSB?

    FTFT (from the...tutorial): LSB has binary compatibility standards, so I can compile once and run anywhere. But if the application is GPL and nontrivial, it shouldn't be that hard to get it into the package repositories in question. Otherwise, it's probably in a scripting language, so the end user doesn't have to build or install it anyway.

    This is really only important for commercial Linux software.
    • Distributing applications in binary form isn't only useful for commercial software: consider Gaim and Inkscape, which use autopackages for this purpose. Apparently Inkscape is hard to install any other way. It's easier to run a pre-compiled executable than compile from source, it's less work for the developer if time isn't wasted packaging for different distributions where it will always be out of date, and it's one of the reasons Windows is so popular. LSB, autopackage and the like are steps in the right

Arithmetic is being able to count up to twenty without taking off your shoes. -- Mickey Mouse

Working...