On Wed, Mar 19, 2008 at 1:35 PM, Robert Daniels <[EMAIL PROTECTED]> wrote: > On Wednesday 19 March 2008 15:53:12 Dan Nicholson wrote: > > This isn't a proper channel for an LSB discussion, but the entire > I would think the LSB Meeting would be the appropriate forum, and Bruce > did ask for input on topics to bring up. (and I don't mean this in the > whiny, argumentative way it looks, I'm just not sure how else to say > it.)
No problem. I think my previous reply might have been a bit aggressive, so sorry for that. > > purpose of the LSB is to allow third parties to create software > > packages for "standard" Linux systems. Where LFS and DIY stop are far > > too minimal for this purpose. For example, how would it be possible > > for Google to package Picasa for Linux if all that was guaranteed was > > what comes in LFS? If you aren't concerned with allowing 3rd party > > packages, then there is no reason to pursue the LSB at all. > > > Package it however they happen to package it now. Just be sure the > dependencies are documented. Beyond that, it should be the > responsibility of the distro to package these dependencies and install > them according to FHS rules. That's how things currently go, but it's a big mess. Let's say I've developed my proprietary app on RHEL and now I want to sell it to some company running Ubuntu. If I want it to be directly installable for them, I have to port the packaging to dpkg and figure out what the dependencies are named on Ubuntu at the least. What if I want to sell it to another company where they use neither RPM nor dpkg? Now I've got 3 packages to maintain. Or, you could write a script that handles the details of the install. OK, except now the binaries are not handled by the native package manager and you require the sysadmin to be familiar with your unusual install method. In both cases, you still need to confirm the package works on systems X, Y and Z for each release or your customers get angry. > > As for the use of RPM, you can see more recent articles and > > discussions on the LSB lists on the topic of package management. It > > is an extremely difficult topic to pursue given the myriad of > > packagers on the various distros. I believe that the current approach > > is to try to create a generic shim layer with backends for the > > specific package managers including RPM, dpkg, etc. > > > As in PackageKit? Not necessarily PackageKit itself, but the idea of it. > This would not be so bad at all. Yep, except PackageKit has a simpler job. It just abstracts the details of the package to the user interface. All the details are just handled in the backends. The packages themselves are still distributed in their native formats. This LSB work would also require a new package format and conversion into the native format before handing off to the system's package manager. > And now I see your reply to my previous mail. I can understand why > vendors would want a more comprehensive specification, but I still > don't see what would be wrong with just documenting the dependencies of > the binary package. Because people really want it to be as easy as "here's the Linux package, install it and go" just like you can do on Windows or Mac. The important thing to remember is that not every Linux user is a power user who is intimately familiar with topics like service initialization, GUI toolkits, packaging, etc. > Perhaps there is something of a user element too. Maybe the LSB > requires the extra software, which could be considered cruft, to > protect users too dumb and/or lazy to read documentation to get > dependency information, and to protect vendors from spurious support > requests from said users. If that's at least part of the reasoning, I > think I might be beginning to understand. If it's me or you, then I would say "too dumb and/or lazy". If it's my mom, then I say those are details she definitely shouldn't care about. I certainly understand the notion of the informed person clicking the "I know what I'm doing" checkbox, but I think the LSB is helping to make "Just Works" attainable for mere mortals. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
