Slashdot Mirror

and i really do have to say "if it's not broke, don't fix it!" not because it ISNT broken (which it isnt anymore thanks to the LSB) but becuase it has been refined many times over... and is very sensible. my system-wide mozilla plugins are saved in /opt/mozilla/plugins, (i thought that was intuitive..) and if users want their own without installing system-wide, they install them in ~/.mozilla/default/*.slt/plugins... EXACTLY where macOS and windows users save them as well!!

/usr and /usr/local are entirely different things, and not the worry of users. they are also very intuitive. /usr is standard system stuff, /usr/local is locally hacked stuff, so i can place 'my' hacked version of any program in /usr/local and override the system one (if i were the sysadmin).

this whole FS reshaping is a rediculous idea and goes against everything the LSB has been tryig to fix, since there are so many deviants of GNU/Linux. i hope this distro dies off damn quickly... (how to lose all your karma in 10 seconds)

It will be unified to some extent, but it will take a bit more time.

There are already unified driver support projects, and there's a huge project at http://www.linuxbase.org/ in which the goal is "to develop and promote a set of standards that will increase compatability among Linux distributions and enable software applications to run on any compliant system."

We will do it, just give us a couple more years. Windows was written over several decades, and Linux is very new still!

Standard can't forbid adding new libraries to environment.

A standard can forbid whatever it likes. I could argue that since "Java" meant not only a programming language (like C++), but also a runtime environment and a set of libraries (larger than what, say, "C standard libraries" provide), that extending those was violating the standard.

In comparison to other standards, we've known for a long time that Java isn't an "Open Standard" like C++ or TCP/IP. (Especially in the past, when Microsoft's offenses occured). There's no public committee to approve amendments to the standard- what Sun says goes. They had wide latitude to redefine the standard as it suited them.

Looking at it from this perspective, one might think Microsoft foolish to sign a contract agreeing to ship Java, when the definition of Java could change in the future. That may be, but they did sign.

(Apple might also be in violation on "nonstandard library extension terms"- but they probably don't have the same contract terms as Microsoft did, and Sun won't waste time targeting a small fish until the big one is taken)

However, I don't even need to discuss new libraries. Microsoft introduced incompatibilities to the language itself. Features like delegate (a new keyword!!) don't provide access to any underlying Windows(tm) functionality- they just change how program internals work.

When GNU C++ did this, they were punished, although by gentle community opposition, rather than lawsuits, as they had no contractual obligation to the standards holder. (And C++ was understood to be a platform-bound language anyhow)

Or if somebody ships a Linux claiming conformance to LSB, but adds some proprietary applications to it, he violates the standard?

The Linux Standard Base specifically mentions that extensions are allowed. Therefore they don't violate the standard. If a standard disallows them, then yes, that's in violation. If a standard is silent on the topic, it needs revision in version x.1.

Linux is damn near there already, but I think the myriad of choices out there is confusing people.

I think the Linux movement at large should be concerned with having a filesystem hierarchy standard [linuxbase.org] and be working for more common implementations (ie: the Linux kernel and other utilities provided by the GNU Project are but a few). There is such a thing as too much choice. Even the two primary package manager formats (rpm and deb) could be unified with Alien [sourceforge.net], which could be intergrated in a Linux distribution. Linux has the installation [caldera.com] and GUI downpat IMO, but good multimedia/P2P programs are scarce, and even the ones that should work dependably don't (I just sent a bug report in to Real.com because RealPlayer 8 farted out on me). Collaboration on a few key projects might be the solution here.

Finally, when you install games - I have Quake III for Linux - I don't think I should have to spend hours finding the right drivers and libs just to run the damn thing in 640x480. I was looking for old Voodoo2 drivers (I'm broke so I need to work with what I got) and 95% percent of the sites which supposedly had it were no longer up-and-running. I guess when the tech bubble burst, alot of people gave up on the Linux movement (or so it would seem). So maybe the last point is there needs to be reliable and comprehensive resources on the net that newbies and seasoned /. geeks can rely on.

Linux deserves to be the defacto os, but it's going to take a coordinate effort to ever see this happen.

Linux is damn near there already, but I think the myriad of choices out there is confusing people.

I think the Linux movement at large should be concerned with having a filesystem hierarchy standard and be working for more common implementations (ie: the Linux kernel and other utilities provided by the GNU Project are but a few). There is such a thing as too much choice. Even the two primary package manager formats (rpm and deb) could be unified with Alien, which could be intergrated in a Linux distribution. Linux has the installation and GUI downpat IMO, but good multimedia/P2P programs are scarce, and even the ones that should work dependably don't (I just sent a bug report in to Real.com because RealPlayer 8 farted out on me). Collaboration on a few key projects might be the solution here.

Finally, when you install games - I have Quake III for Linux - I don't think I should have to spend hours finding the right drivers and libs just to run the damn thing in 640x480. I was looking for old Voodoo2 drivers (I'm broke so I need to work with what I got) and 95% percent of the sites which supposedly had it were no longer up-and-running. I guess when the tech bubble burst, alot of people gave up on the Linux movement (or so it would seem). So maybe the last point is there needs to be reliable and comprehensive resources on the net that newbies and seasoned /. geeks can rely on.

Linux deserves to be the defacto os, but it's going to take a coordinate effort to ever see this happen. And it can happen. *Ahem* I'm finished now.

If Redhat is pushing (or wants to push) the linux community towards more standardisation, why don't they join the unitedlinux effort then ?


The standardization effort is LSB. "UnitedLinux" is more of a marketing tactic from Suse than a standardization effort...


If suse, caldera, conectiva and openlinux can put aside their own goals

Two of these, caldera (openlinux is a product of them) and TurboLinux, are dead companies (as far as Linux development goes... their developers are gone). This isn't four companies pooling their efforts, this is SuSE desperately trying to counter Red Hat and signing up dead/severely hurting companies and give the impression of something more.

Linus doesn't standardize Linux - he rules the kernel, but Linux is much more than a kernel.

Libraries (ABIs and availability), some configuration files and tools are much more important - a kernel should basically "just work" from an application's point of view. This sort of standardization is what LSB tries to achieve.

As far as UnitedLinux trying to bring standards to Linux - give me a break. This is just SuSE trying to give an impression of it. 2 of the 4 distributions are dead (TurboLinux, Caldera) with little/no development. Connectiva also slimmed down quite a bit. UnitedLinux is another name for SuSE, and is no more a standard than SuSE is. The standard is LSB, the de facto implementation of a standard Linux distribution for the market they're targetting is Red Hat Linux.

It's what you get 'given' from the company, different distros have different focuses, easy of use, stability, performance, leading edge, business, developers, etc.
There are also file, location and library differences, which appear to be driven by the distros above aims, installing red hat packages on SuSE can be a nightmare! Though this should be aliviated through the Linux Standard Base

Once you start downloading other packages your out of the distro.

Close to... It's called Linux Standard Base. A good, 30+ years of Unix practice in one spec sheet... But it has yet to be adopted by all major players. And it has yet to be agreed upon by application programmers as well. Add to this the fact that quite a few of these participants feel free to violate the standards when it arranges them.

And the LSB doesn't touch the desktop in any way either, so no desktop consistency can be hoped from there... I do hope RedHat succeeds in its long-overdue effort, or if it fails, that it at least sets the trend for other major distros and put some lead into Gnome/KDE programmers' heads - "cooperate".

The real question is, of course, with the Linux Standard Base around, why do we need an additional set of standards, driven by a handful of companies as opposed to an independent organisation? I don't know the answer, but I guess it's a good thing that UnitedLinux claims to be open, in the sense that any Linux distribution that chooses to adhere to their standards can join the group. But will we ever see RedHat become part of UnitedLinux? I have my doubts...

Linux Standard Base
Standards for directory structure, Object Format, libs, tools, shells, user & groups, system init and more
currently Caldera, Mandrake, RedHat && SuSE are LSB Certified

i thought solaris, being UNIX was posix complient, and so didnt need to be LSB compliant.

Any LSB conforming operating system can use source RPM packages that meet the LSB specs. This should expand the selection of free software that runs on the Solaris operating environment as well as make it easier to install.

It seems like such a logical choice to host it at http://www.linuxbase.org/. This way, people can learn how to install the standard base from scratch.

dpkg has it's own technical advantages too, such as suggests and recommends, and diversions. It also, as far as I know, integrates more closely with apt, allowing you to put packages on hold and handle systems which mix packages from a variety of sources (eg: base system from latest stable, latest version of package foo from unstable or testing).

Ignoring for the moment that IMAP4, ical, vcard and MAPI are all very different things, there's a fatal flaw in your analogy - you're equating things are are established, open standards to something that is comparitively closed. A more appropriate analogy would be to compare IMAP with POP3 - they're both open, established standards that solve the same problem in different ways, each with their own advantages and disadvantages. Trying to force everyone currently using POP3, or some other method they've come up with themselves, to use IMAP instead would cause chaos - IMAP would have to be expanded to handle functionality that currently only exists in POP3, and the changeover would be a nightmare for all concerned.

This is why the LSB states that here that "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.". To me, alien sounds like a fine way of installing LSB-conformant RPM packages. The LSB have realised that trying to force all distributions to switch to the RPM format internally would be a fatal mistake - the toll on the Debian project would be enormous (volunteers really don't have time to repackage 8000+ packages to suit the desires of a committee), and it would destroy the usefulness of innovative new distributions like Gentoo.

Maybe I'm missing your point slightly, but I really don't see what switching Debian to the RPM format would achieve apart from causing an entire upheaval of Debian's entire package archive and development process, not to mention all of the Debian servers out there which can currently be so easily upgraded to the latest stable Debian version without so much as a reboot. You seem to say that it'd be for the greater good of Linux, but I personally think that keeping Debian around as a viable free alternative to the commercial distributions is a far more important thing to the future of Linux than some piddling squabbles over a file format.

If you develop in C++, make the effort to upgrade to GCC 3.2 and the new style standard C++ library style of programming. Believe me it's worth the effort. The only execption to this is if your interacting/recompiling with older KDE or Mozilla. The latter needs GCC-2.96 to load plugins.

Configs in /etc, services in /etc/init.d, documentation in /usr/share/doc, user bins in /usr/bin unless your apps is necessary to rescue to the system, sbin for yoru admin bins, /usr/lib for your libraries, /usr/share for everything else, RPM for your packages, stable releases of glibc and gcc for C library and compiler, etc.

Do you want to know more?

A commercial OS would have enforce such a standard on all its engineering teams, eliminating such problems, and therefore eliminating the need that the user should check out if there is a new version available or not!

Good points, but it's not nearly as bad as you make it sound. At least not anymore.

Linux Standard Base, people....

We already got standards..

- Linux Standard Base (LSB) (Redhat, Mandrake and SusE have just become LSB-compliant)
- Filesystem Hierarchy Standard (FHS)

The Linux Standard Base mandates that all compliant distributions must be able to install software that comes as an RPM. There is more information here. RPM's are universal.

LSB is an attempt to standardize many aspects of a Linux distribution, such as binary (executable) file format, dynamic libraries, packages, and system initialization. They also standardize file system format, and the LSB 1.2 is FHS 2.2 compliant.

LSB is an attempt to standardize many aspects of a Linux distribution, such as binary (executable) file format, dynamic libraries, packages, and system initialization. They also standardize file system format, and the LSB 1.2 is FHS 2.2 compliant.

Conduct your own LSB test on your distro

Red Carpet makes all other package management systems look silly, including rpm, and up2date.

In a world like ours with Joe and Bob trying to unify/standardize their linux (United Linux, LSB), and Fred and Sam trying to stabalize theirs (Debian GNU/Linux), users are left to figure out what might be best, safest, easiest to use.

If your a newbie, do yourself a faver and use Ximian Gnome, red-carpet in particular. I use KDE, but still use red-carpet to keep my system up to date when a new security hole needs patching, or to do cool stuff like install ruby.

There is life beyond apt.

Doesn't my hometown have beatiful girls?

Well, I hate to admit it, but this area is one of the fiew that Windows is still king.

Like in other replies, there is just one file to install anything on a windows machine. The .exe creates directories, updates as needed (the updates are included usually in the .exe), coppies files to directories, writes to the regestry, and cleans up after its self. The .exe installer has become _very_ efficent.

Hmm...It isn't exactly a package managment utility though. Unless installation and removal are the only features that a package management system need to have. Windows installers don't give even half of the features that you would expect of a decent package management utility. Most notably, it can't even tell you what other packages rely on this package of which other packages this package relies on. Let alone other nifty features like md5 check sums, build and install information and a list of which files where installed where.

Linux, however, lacks in this arena. To just configure _source_ to be ready to compile the user/installer must go to shell and run ./configure.sh And that's just to make source ready to go.

This can not be comapared to package managment. The configure script is for building and was never intended for managing installs. It serves it purpose well allowing the same source code to be built under multiple different architectures and operating systems. A truly excellent utility

Another shortfall of RPMs is the fact that when an RMP is downloaded, you _ONLY_ download the binary for the program you want to run. The RPM usually does not include updates to dependances, it expects you to fix them your self.

That is not a shortfall in itself. A package should only contain the binary for the program(s) the package is for. Shared libaries that are built independently should be provided independently. The trouble with RPM is that although it will tell you the name of the thing that it requires it won't tell you how or where to get it. The way around that is to use an apt-get type wrapper around RPM because really that sort of information should be stored in a repository not in the package itself. Otherwise, when the name of a mirror site changes, all the distributed packages would have the wrong mirror name.

So, my far fetched idiea is 1) Have a central repository for _ALL_ configuration and initialization files. (like a regestry?)

You mean like /etc ? Seriously, the idea of one file (registry) conatining all the configuration is a nightmare. Especially the way it is implemented in windows. It is very difficult to edit the registry (for a layman that is) under windows and easy to accidently change the configuration for the wrong program. With all the configuration files in a standard place like /etc they are easy to find. Typically the plain text styled configuration files that are used under Linux are easy to change even for the layman (ok...forget sendmail).

3) Have a standard that is agreed upon across the board for files to be included in an RPM and make them generic. ex. An RPM for Red Hat should also work under Mandrake. (I don't know if this is possible beacuse of file placement, directory, etc. discrepencies)

A lot of that, although not RPM specific, is covered in the Linx Standard Base that once adopted will help a lot of the compatability problems across distributions.

And the Linux Standards Base.

I think the biggest thing we need with rpm (and other distro systems) is standardized package locations.

You mean something like a Filesystem Hierarchy Standard? Or maybe even a Linux Standard Base?

Jay (=
(Is there a website that rates distributions according to their adherance to these standards?)

5. It does not use any interface or data format that is not required to be provided by a conforming implementation, unless:

[...]

* The use of that interface or data format, as well as its source, is identified in the documentation of the application.

UnitedLinux appears to attain to standardize the core of Linux distributions similar to the goal of the Linux Standards Base project from what I've read thus far. What distinguishes the UL project from the LSB project: goals? approach? an effort to competitively differentiate Caldera from RedHat?

At first glance, this project appears to be geared more to bolstering the marketing position of the distros (esp. Caldera) involved relative to RedHat than to furthering overall Linux market penetration. As a developer, I'd like to be clear on what you're trying to accomplish.

The Linux Standard Base might have been something they should have agreed on. Or perhaps they will anyways. Anyone knows more?

There are de-facto standards which are imposed more or less by a single company (such as RedHat), and there are standards which are developed by independent organizations (such as the Free Standards Group). I think an open (in every sense) operating system such as Linux deserves a standard that has grown dynamically out of the collaboration of a multitude of people, from companies as well as from independent organizations. If a company like RedHat is powerful enough to impose de-facto standards on the Linux community, this might hurt the evolution of Linux in the long run.

While basically all major Linux distributions contribute to the Linux Standard Base, not all of them follow the specifications equally well. The general opinion seems to be that RedHat in particular does not implement the LSB very strictly. One goal of the United Linux project, as far as I understand, is to create a distribution that follows the LSB very closely, and has enough market share to compete with RedHat. So instead of imposing yet another standard, one should see the project as an attempt to strengthen an already existing standard.

If somebody is wondering what LSB is, well no, its not the pre-precursor of LSD; it is the Linux Standard Base

cheers

rmstar

Simply because the overhwleming majority of its users call it thus. In the future `Linux' will have a more stricter definition: it will be an Operating System that conforms to the Linux Standards base.

This is the one thing that really irritates me about SuSE. I love it otherwise. Strange thing is, SuSE ranked very well according to this Linux Standards Base test. I don't know related it is, but it's being touted as SuSE's commitment to standards. I would guess that the system configuration is related to the way YAST is set up.

• Reasons to Use SuSE Linux
  
• Choose from among XFS, ext2, ext3, reiserfs, and others during install
• choose to encrypt your filesystem
• free security updates, unlike RedHat
• improved YaST2, the ultamite in system configuration utilities, let's you configure everything from a DHCP server to CUPS
• YaST Online Update, for automatic upgrading of your RPMs
• conformance to the LSB, the only compliant distro so far
• the most secure distro, according to LWN.net research
• Personal Firewall configuration through YaST
• 90 days of tech support through email or telephone with the Professional version

I've recently gotten pretty annoyed with the way SuSE has been set up, so I decided to find out how it fared against the FHS. Shockingly, SuSE did the best on this test. It still seems messy to me, though.

/opt is not deprecated. In fact it is required that LSB compliant applications are installed under /opt You can download the latest version of the FHS here and the LSB specification here.

While I agree competition is good I find it important, that competition, once it has produced enough "critical mass" gets joined into both environments as a base, a standard.

However, I am a little sad to see the way things seem to work:

I hope this won't get interpretated as a troll. It is just a listing of negative impressions I have and feel they sting me.

I am really into Eye-Candy myself but it is not what makes my work being done. I see there are many MANY more issues both teams should address in a joint-venture:

• Inter Process Communication on application-scripting level. Let's face it, most applications come with their own scripting support. For Gimp and XChat you can use either Python or Perl. For Emacs you can use emacs-lisp. Others use Tcl. And this is all nice, but is there a common Linux-Scripting API ? Something like ARexx was on the Amiga (not really an API but a powerfull language for any application) or WSH (Windows Scripting Host, the precedessor of .NET if I dare to say) on M$ Windows ? I think the desktops would be the first place to define such a thing, because IPC macroing is mostly a users/powerusers thing and they are the ones who get addressed by any desktop at most. There is more to user-level IPC than Drag&Drop.(And I am not talking about "Word-Macros",mind you ;-))
• How many MIME-definitions do you have !? Uh, right, and how cool it was to take the Window$ approach of identifying files by their extensions...I found no place yet neither in Gnome nor KDE to identify files by a match against certain rules...
• I am in need for global keyboard shortcuts.
• I want applications to start implementing their functionality as exportable (to the scripting host) commands, adding the additional benefit, that the user can fully (!) customize all menus and keyboard- and mouse-events. This is configurability ! Not the fact, that I can set some themes...(both Desktops at least allow for global keyboard definitions per desktop system, I know).
• How many contact lists do you have ? I have one in KMail (is up quicker than Evo and KDE's default), one in Opera (adding while surfing) and one in Evolution. Cool ? Not ! And the same goes for bookmarks of the browsers. Yes, I use Opera mainly but sometimes I just use Konqueror or Mozilla. The import/export is not enough.

• I want a common base !(earth shakes ;-))

  Now, I, as a user and developer, do that movement, that the ballet-dancers do (and which I lack the english expression for), that moment when they have their legs completely spread apart while touching the ground. I got some training in this myself, I touch the "Desk's Top" but it hurts me often, still.

  I know this ain't easy. There have been huge flame-wars, not so long ago between both teams, software-fidelity is some sort of spiritual believe...(Emacs vs. Vi, KDE vs, Gnome, Windows vs. RestOfTheWorld, etc.). A slight hope on the horizon could be the Linux Standard Base LSB. In any case some head must be found both sides trust and we could have M$ struggle also on the desktop within four to five years. I tell you !!! :-D

  Also, I am pretty sure, this all will happen sooner or later. But I find it disturbing to see not much sophisticated movement below the surface (which, in addition, would be quite easy to implement) and users wanting theme-engines and "the-looks congiguration" mainly.

I'm sure you mean "the single standardized Linux distribution."

No, grandparent referred to the Linux Standard Base.

To pre-empt the old joke: "All your Linux standard base are belong to the Free Standards Group."

The real issue is finding the configuration file; if you're using a distro you're not used to, then one often has to resort to using find. This is exactly what the Linux Standards Base was designed to avoid, and if all distros were to follow this model then I can't see that there is any real problem.

At the end of the day, we're not talking about things like setting background pictures in the window manager, we're talking about setting up mailservers, webservers and the like. If you're not cluefull enough to edit a text file then you're not cluefull enough to be put in charge of setting one of these servers up either.

Because there is only one captain on the ship, Apple. Good luck fixing it in the Linux world. The only way it might have a chance of working IMHO is if such a proposal gets included the Linux Standard Base. Here's a bold idea, why not copy the way Apple does it??? No need to reinvent the wheel...

-adnans

From discussion with Debain users (and time spent administering Debian boxed at my workplace) Debian's rpm support doesn't work that well for anything apart from large self-contained statically compiled packages. The problem being that the Linux Standards Base will probably be considered the definition of what a Linux distro is in a couple of years (and is starting to be used as a yardstick these days). Yes Debian ostensibly supports the LSB via alien, but how well?

That's a very good question (and one nobody bothered to answer in the ensuing discussion). At present, it probably doesn't support it at all, excluding the rudimentary support for LSB packages joeyh added to alien 8.00. I can't locate any intent to package statement for lsb or lsb-rpm (the former being the LSB's core dependency, the latter being the RPM specified by LSB). The only packaged LSB component is lsb_release.

I'd have to do a bit more digging to figure out if anyone is actually working on this stuff.

It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable.
Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information.

Of course they provide control information - if they didn't, they wouldn't be management systems would they? If alien still removes this information it does not do a good job of installing packages. Rather it turns those packages into dumb archives.

Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts)

Initscripts live in /etc/init.d. Other locations are not correct. Red Hat, SuSEm and other people who once put initscripts in other (now incorrect) locations are moving towards this.

AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB.

It seems you're in error. RPM 3 format packages are specified in the Linux standards base.

DJB has a number of valid criticisms [cr.yp.to] (of the FHS) that are as of yet not addressed by the LSB, or more accurately, the FHS.

Good or bad, its a standard. You'll get more pain from not sticking to a standard and fragmenting Linux than you will from adopting a standard even if you don't like every part of it. Some of DJBs recommendations (eg, a registered namespace for apps) coudl easily be included in the LSB, just as suiggested / recommended dependcies could be added to RPM if so desired (says someone who happily maintains a 3GB APT repository filled wit h RPM packages for the Red Hat machines at his workplace).

in fact the Debian Project has made FHS support a specific requirement [debian.org] in their official policy manual.

Excellent. But they really should do the same with the LSB.

The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant.

True, another poster made this point earlier and I agree: all Linux distribtions should completely support RPM 3.05 packages.

Offical standard RPMs are handled by Debian via Alien flawlessly

No they are not, if they remove control information as you have earlier stated. Without this data there is no `management' and it seems alien can hardly be trusted to install a large amount of interdependent software.

Debian's pretty good with FHS support, so is RH: RH has likewise moved all /usr/doc files into /usr/share/doc, and haven't used /opt in years. Suse moved their initscripts from /sbin/init.d to the proper location, but still /opt kde. I'm glad that these efforts are being made, however greater effort on fundamental issues like the packaging system needs to be performed to stop Linux fragmenting.

Theoretically, software developers should only have to release their files as .TGZ archives

If they added standardized installs, uninstalls, information about the relationships between packages, querying / verifying machinisms, etc, this would be possible. Unfortunately they don't and it isn't: hence the need for packaging.

As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen.

I am well aware of the FHS and APT. I am well aware alien doesn't handle RPM packages beyong turning them into dumb archives. I just wanted to se if there is any attempt under way to fix this.

I'm also especially aware of how APT works: I run an APT repository for the Red Hat systems at work and my own machcine, with around 3000 packages.

Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.

There are no `APT' packages - you means debs. APT run on top of the packaging system. Yes, recommended / suggested dependencies are very useful, and its good that .deb provides this. So is transaction handling for the rpm database - its good that rpm provides this. They each have their advanatges. I'd like to see the good features of deb added into RPM, and the LSB updated to this new version.

I am heartened to see that you haven't been down modded, I I hope that my post has been informative.

Thankyou.

Mike

-castlan

It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable.
Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information.

Of course they provide control information - if they didn't, they wouldn't be management systems would they? If alien still removes this information it does not do a good job of installing packages. Rather it turns those packages into dumb archives.

Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts)

Initscripts live in /etc/init.d. Other locations are not correct. Red Hat, SuSEm and other people who once put initscripts in other (now incorrect) locations are moving towards this.

AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB.

It seems you're in error. RPM 3 format packages are specified in the Linux standards base.

DJB has a number of valid criticisms [cr.yp.to] (of the FHS) that are as of yet not addressed by the LSB, or more accurately, the FHS.

Good or bad, its a standard. You'll get more pain from not sticking to a standard and fragmenting Linux than you will from adopting a standard even if you don't like every part of it. Some of DJBs recommendations (eg, a registered namespace for apps) coudl easily be included in the LSB, just as suiggested / recommended dependcies could be added to RPM if so desired (says someone who happily maintains a 3GB APT repository filled wit h RPM packages for the Red Hat machines at his workplace).

in fact the Debian Project has made FHS support a specific requirement [debian.org] in their official policy manual.

Excellent. But they really should do the same with the LSB.

The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant.

True, another poster made this point earlier and I agree: all Linux distribtions should completely support RPM 3.05 packages.

Offical standard RPMs are handled by Debian via Alien flawlessly

No they are not, if they remove control information as you have earlier stated. Without this data there is no `management' and it seems alien can hardly be trusted to install a large amount of interdependent software.

Debian's pretty good with FHS support, so is RH: RH has likewise moved all /usr/doc files into /usr/share/doc, and haven't used /opt in years. Suse moved their initscripts from /sbin/init.d to the proper location, but still /opt kde. I'm glad that these efforts are being made, however greater effort on fundamental issues like the packaging system needs to be performed to stop Linux fragmenting.

Theoretically, software developers should only have to release their files as .TGZ archives

If they added standardized installs, uninstalls, information about the relationships between packages, querying / verifying machinisms, etc, this would be possible. Unfortunately they don't and it isn't: hence the need for packaging.

As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen.

I am well aware of the FHS and APT. I am well aware alien doesn't handle RPM packages beyong turning them into dumb archives. I just wanted to se if there is any attempt under way to fix this.

I'm also especially aware of how APT works: I run an APT repository for the Red Hat systems at work and my own machcine, with around 3000 packages.

Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.

There are no `APT' packages - you means debs. APT run on top of the packaging system. Yes, recommended / suggested dependencies are very useful, and its good that .deb provides this. So is transaction handling for the rpm database - its good that rpm provides this. They each have their advanatges. I'd like to see the good features of deb added into RPM, and the LSB updated to this new version.

I am heartened to see that you haven't been down modded, I I hope that my post has been informative.

Thankyou.

Mike

-castlan

From discussion with Debain users (and time spent administering Debian boxed at my workplace) Debian's rpm support doesn't work that well for anything apart from large self-contained statically compiled packages. The problem being that the Linux Standards Base will probably be considered the definition of what a Linux distro is in a couple of years (and is starting to be used as a yardstick these days). Yes Debian ostensibly supports the LSB via alien, but how well?

The distributions which put initscripts in nonstandard places have had to change, those install packages into /opt have had to change, and if they haven't, they've been looked upon negatively (and rightly so) for their lack of standards support. So how well does alien work, and would you use it to install some, or even most software on your system? A standardized packaging system is useful for more than just closed source apps - its useful for every open source app maintainer that's tired of maintaining different sets of packages for Red hat, Suse, Debian, Mandrake, Connectiva, and every other distro out there. Theoretically, the KDE people (for example) should only have to release one set of packages per OS. Doing otherwise wastes a great amoutn of time that could be used elsewhere.

And yeah, I'm a Red Hat user who has posted a non 100% supportive comment about Debian in a Debian release news item. /me waits for the inevitable negative moderations from people who disagree with what I'm saying but can't voice their own opinions and repond maturely.

As Linux becomes more and more popular, the question becomes more and more important: which distribution should I use? I use SuSE Linux for several reasons. Firstly, it is the most LSB-compliant distribution. It comes with huge amounts of software (6 CDs of binaries for the Professional version, and (arguably) SuSE has the largest security team. SuSE updates are free and released often. Announcements are even GPG-signed. According to LWN.net research, SuSE has the best security after TurboLinux (which much less security-related bugs than RedHat.

On a more subjective note, many consider SuSE to be the most polished distribution, and YaST2 is considered one of the best all-around system configuration utilities.

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

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