Slashdot Mirror

← Back to Stories (view on slashdot.org)

Three Major Linux Distributions Certified LSB Compliant

Posted by timothy on from the oh-you're-so-compliant dept.

KevinDumpsCore writes "RedHat, Mandrake, and SuSE are now certified LSB compliant!" Here's the announcement on the Free Standards Group's site. The Linux Standards Base (check out these related Slashdot posts) has been working for years to perhaps tame the what-lives-where cross-distro craziness. (Of course, distro makers are under no obligation to comply with the LSB's choices.)

10 of 188 comments (clear)

  1. What about Debian? by shadwwulf · · Score: 2, Interesting

    What's Debian's status in this matter?

    1. Re:What about Debian? by Trevelyan · · Score: 3, Interesting

      The are some problems, for some reason LSB specifies a standard package, ie RPM
      I do not know why, I see no reason for it, but obvious this is a problem for Debian, which has its own (imo superior) package (debs).

      This article from Debian planet, is about a sudo package you can install, which depends on all the LSB stuff (thus gets them installed, with some caveats)
      As to RPM, Debian wont move from debs, but I believe they make a wrapper so that dpkg can understand them, see /usr/share/doc/lsb/README.Debian.gz

      I will not install lsb, cause it wants lpr (BSD print deamon) and I already use CUPS (a SysV print deamon), as well as other stuff.

  2. RPM... by matman · · Score: 5, Interesting

    It's too bad that the LSB people havn't yet taken on packaging issues. They've effectively chickened out by just recommending RPM. The best features of RPM, DEB and the BSD ports system should be reflected in a new packaging format for people to work towards using. Not only should this format be recommended by the LSB, but the LSB should define policies for the use of the format - package name and version formats, dependencies and package alias names, source package handling, non-official packages, etc. This really is necessary to get distribution of commercial software on Linux; testing for and supporting distribution differences is just too expensive for most companies. This is not to say that everyone supporting RPM won't help, but rather that policies are needed to really make it work, and that we may as well get a more optimal package management system happening :)

    1. Re:RPM... by cant_get_a_good_nick · · Score: 4, Interesting

      The BSD ports setup pretty much requires source distribution and the target audience for LSB isn't interested in that.

      BSD also has binary packages, which mesh with the ports system. They're .tgz packages with the normal pre and postinstall scripts available in the package. I always thought of the BSD system as pretty slick, a source model and a binary package model that mesh well. Anything I installed from ports I remove with the package tools. I can check for new versions of all externally installed software (packages and ports) with the same command. They blend well enough for me that I kind of see them as one system.

  3. Versions? by anakog · · Score: 2, Interesting
    The article forgot to mention which versions of these distributions got certified.

    I am curious in particular about Red Hat's distro. I am sure that 8.0 will be LSB compliant but does anyone know about 7.3?

  4. LSB vs FHS by peterpi · · Score: 2, Interesting

    Forgive my ignorance, but how does the LSB relate to the Filesystem Hierachy Standard. Is it a replacement?

  5. Re:Eh? What are YOU talking about? by __david__ · · Score: 2, Interesting

    Quoth the heathen:
    > But NO, window managers must remain ordinary
    > applications, otherwise X turns into something
    > brain damaged like Windows or a Mac.

    Brain damaged? Who's spouting FUD now? Mac's have Window Managers too:

    [localhost:~] david% ps axwww | grep Core
    73 ?? Ss 3:15.50 /System/Library/CoreServices/WindowServer
    228 ?? Ss 0:00.29 /System/Library/CoreServices/coreservicesd
    272 ?? Ss 0:00.10 /System/Library/CoreServices/SecurityServer
    286 ?? Ss 0:00.71 /System/Library/CoreServices/loginwindow.app/login window console
    289 ?? Ss 0:03.53 /System/Library/CoreServices/pbs
    303 ?? S 0:05.07 /System/Library/CoreServices/Finder.app/Contents/M acOS/Finder -psn_0_262145
    304 ?? S 0:01.21 /System/Library/CoreServices/Dock.app/Contents/Mac OS/Dock -psn_0_393217
    306 ?? S 0:08.16 /System/Library/CoreServices/SystemUIServer.app/Co ntents/MacOS/SystemUIServer -psn_0_655361

    Mac OS X is less brain damaged than you think.

    -David

    --
    There. Now go play some cool javascript games!
  6. Use of packaging to distribute software internally by aegilops · · Score: 2, Interesting

    Interesting thread RE comparisons between RPM, apt, ports etc which I have some familiarity with but not enough to argue with the beards. However what I would like to see is some work on how an admin can centralise package distribution to internal users.

    From personal experience, most of these package managers are focused on the end user making the decision to instigate an upgrade, however that is achieved. The execution of the upgrade is also within the hands of the end-user. However consider the scenario where you have a number of open source desktops and you have responsibility for ensuring that your users (a) have access to the applications they need (which will vary from user to user), (b) incorporate upgrades on a mandatory basis based upon criteria that you specify (e.g. security patches, other app patches you decide are required), (c) these applications are available to users wherever they log in, (d) they integrate well with whatever window manager you choose to use.

    Now, I know this is easy to say and represents a lot of work, especially the WM integration (exactly how many WMs are there out there?) but consider from a corporate perspective - it's not going to look to good when you start advocating the current methodologies for obtaining packaged software for desktops when compared with MS Group Policy package distribution, Novell ZENworks, IBM Tivoli ...

    If you're going to review the current approaches to package distribution, and hopefully build an open standard at some point to fit in with LSB, then at least keep the door open for a centralised software distribution mechanisms.

    Aegilops

  7. Wrong. Simple counterexample. by BlowCat · · Score: 3, Interesting
    Suppose that some commercial development tool requires gcc-3.0.1 or above. They make an RPM. What should they require? "gcc >= 3.0.1"? Wrong. A user of RedHat 7.2 can have gcc-2.96 and gcc3-3.0.4. Maybe "gcc3 >= 3.0.1". Nope. RedHat 8.0 will have gcc-3.1 (maybe even gcc-3.2) and no gcc3 package.

    Handling of incompatible versions of the same software is done ad hoc, without any strictly established and well designed rules. Either the old or the new version gets a number appended to the package name (glib10, kde2, gcc3).

  8. I love this stuff. by ubernostrum · · Score: 2, Interesting

    I've been running Red Hat for two years now. Where's the "dependency hell" everybody talks about? I've gone from 7.0 to 7.3, doing each upgrade in turn, installed all sorts of stuff in between upgrades, never had any problems. So I have some issues with what you call a "typical" install on Linux...