Re: Choosing a boot loader for LFS 7.0
Alexander E. Patrakov wrote: > Hello, > > as explained in http://wiki.linuxfromscratch.org/lfs/ticket/2161 (a blocker), > due to recent changes in e2fsprogs, Grub-0.97 no longer works. Grub, Grub2, Lilo have been mentioned. A quick google search brings as result 3: http://gag.sourceforge.net/ GAG (initials, in spanish, of Graphical Boot Manager) is a Boot Manager program. It's loaded when the computer is turned on and allows you to choose the operating system you want to use. up to 9 operating systems, released under the GNU-GPL. Haven't looked at it yet. though result 6 of that search return looks much more interesting to me: http://gujin.sourceforge.net/ freshmeat description: Gujin is a PC boot loader which can analyze your partitions and filesystems. It finds the Linux kernel images available, as well as other bootable partitions (for *BSD, MS-DOS, Windows, etc.), files (*.kgz) and bootable disk images (*.bdi), and displays a graphical menu for selecting which system to boot. Gujin boots Linux kernel using the documented interface, like LILO and GRUB, so it doesn't need any other pre-installed bootloader. It can also directly load gzip'ed ELF32 or ELF64 files, with a simple interface to collect real-mode BIOS data. There is no need to execute anything after making a new kernel: just copy the kernel image file into the "/boot" directory, with a standard name. Gujin is written almost entirely in C with GCC, and it fully executes in real mode to be as compatible as possible. requirements: you will need also GCC-4.2.3 and Binutils-2.18 just a couple of other optons that can be concidered. Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/19, J. Greenlees <[EMAIL PROTECTED]>: > GAG Not tested yet, will do now. > http://gujin.sourceforge.net/ Tested seveal months ago, had a conversation with the author about the QEMU bug (unfortunately, the proposed fix broke something in SUSE) and the bogus LANG=en argument being appended to the kernel command line. Drawbacks: * Triggers a keyboard/mouse emulation bug in QEMU and KVM * Has no config file, attempts to guess append the "root=/dev/hdXY" parameter automatically. * Thus, is incompatible with libata until this guessing is disabled (one can do it from the command line of the installer). * This manual override works only on a global basis, thus, one cannot explain that one kernel (from a host distro) should be used with one root partition, while the other kernel has another root. The last item makes this boot loader unsuitable for LFS, since LFS relies on the ability to dual-boot LFS and the host until one installs a DHCP client and a web browser. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/19, J. Greenlees <[EMAIL PROTECTED]>: > http://gag.sourceforge.net/ Requires Borland Turbo Assembler (available for MS-DOS only) in order to be recompiled. LFS cannot assume that this proprietary OS is installed. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
Alexander E. Patrakov wrote: > 2008/3/19, J. Greenlees <[EMAIL PROTECTED]>: >> http://gag.sourceforge.net/ > > Requires Borland Turbo Assembler (available for MS-DOS only) in order > to be recompiled. LFS cannot assume that this proprietary OS is > installed. > hmm, I wonder if my borland Kylix3 enterprise edition has support for that. unfortunately, it won't install on a system with a kernel version above 2.4. I know I have the free version of Kylix3 kicking around as well, but it hits the same limitation re kernel version. I doubt it's actually the kernel version, more likely the toolchain changes for the 2.6 kernel, but it does not play nice even with an upgrade of os after install. I'll take a look at it in my [ sarcasm ] copious [/sarcasm ] spare time and see if I can build it, and maybe port it to gcc. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
J. Greenlees wrote: > Alexander E. Patrakov wrote: >> 2008/3/19, J. Greenlees <[EMAIL PROTECTED]>: >>> http://gag.sourceforge.net/ >> Requires Borland Turbo Assembler (available for MS-DOS only) in order >> to be recompiled. LFS cannot assume that this proprietary OS is >> installed. >> > hmm, I wonder if my borland Kylix3 enterprise edition has support for > that. unfortunately, it won't install on a system with a kernel version > above 2.4. > I know I have the free version of Kylix3 kicking around as well, but it > hits the same limitation re kernel version. I doubt it's actually the > kernel version, more likely the toolchain changes for the 2.6 kernel, > but it does not play nice even with an upgrade of os after install. > > I'll take a look at it in my [ sarcasm ] copious [/sarcasm ] spare time > and see if I can build it, and maybe port it to gcc. I just looked closer at gag, it still requires either lilo or grub to boot, it can't recognise the kernel image by iself. kills that idea. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
On Mon, Mar 17, 2008 at 08:46:31AM +0500, Alexander E. Patrakov wrote: > Did anyone investigate the boot loader options further? What should be done > for > LFS-7.0? Based on what I've read, I vote for switching to LILO as the default. This has the advantage of making things easier for bringing x86_64 support into LFS, that is, if we're still wantint to do that for 7.0. Might still be alright to mention grub (and maybe even grub2) in the book but list the pros and cons for each and why we chose LILO as the default. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
On Wed, 19 Mar 2008 08:07:01 -0600, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > On Mon, Mar 17, 2008 at 08:46:31AM +0500, Alexander E. Patrakov wrote: >> Did anyone investigate the boot loader options further? What should be > done for >> LFS-7.0? > > Based on what I've read, I vote for switching to LILO as the default. > This has the advantage of making things easier for bringing x86_64 > support into LFS, that is, if we're still wantint to do that for 7.0. Does LILO still require NASM? My (not-so-strict) criteria for a boot-loader are: 1) Is compatible with other packages in LFS 2) Is compatible with the widest range of architectures as possible - with the assumption that at some point x86, x86-64 and possibly PPC will be supported if not by stock-LFS, by CLFS and having a common-bootloader between them just makes sense from a support POV. 3) Doesn't come with 'the kitchen sink' - last I looked, GRUB2 was spawning scripting abilities, JPEG, TGA and PNG parsers, audio file parsers, etc. I just want it to jumpstart my kernel, not provide its own desktop-environment! (I understand that some people like graphical bootloaders where image format parsing might be useful, but I personally spend so little time looking at the boot menu I don't see the benefit myself). Out of the ones Alexander listed, I've only ever heard of Gujin but have never tried it. As is probably evident, out of laziness, I don't install GRUB as per the book's instructions - I just rely on my host system's GRUB. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/19, Matthew Burgess <[EMAIL PROTECTED]>: > Does LILO still require NASM? No, but it requires bin86. -- Alexander E. Patrakov (writing from FreeBSD 7.0 amd64) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
Jeremy Huntwork wrote: > On Mon, Mar 17, 2008 at 08:46:31AM +0500, Alexander E. Patrakov wrote: >> Did anyone investigate the boot loader options further? What should be done >> for >> LFS-7.0? > > Based on what I've read, I vote for switching to LILO as the default. > This has the advantage of making things easier for bringing x86_64 > support into LFS, that is, if we're still wantint to do that for 7.0. > > Might still be alright to mention grub (and maybe even grub2) in the > book but list the pros and cons for each and why we chose LILO as the > default. My position is that we should stay with grup 0.97 and the compatible version of e2fsprogs until upstream gets the problems worked out. Of course, not using the most recent packages will require a note in the book explaining the issue. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/19, Bruce Dubbs <[EMAIL PROTECTED]>: > My position is that we should stay with grup 0.97 and the compatible > version of e2fsprogs until upstream gets the problems worked out. This doesn't work: GRUB has to be compatible not only with the LFS version of e2fsprogs, but also with the hosts's version. We expect GRUB to boot not only LFS, but also a host distro. If a host distro uses a new ext3 filesystem, we have a big problem. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
Selon Bruce Dubbs <[EMAIL PROTECTED]>: > My position is that we should stay with grup 0.97 and the compatible > version of e2fsprogs until upstream gets the problems worked out. Of > course, not using the most recent packages will require a note in the > book explaining the issue. > Why prefer to use an older e2fsprogs package than use existing grub-0.9.7 inodesize patch to support different inode sizes? Or you could change default inodesize to remain to 128 during file system creation with -I 128 option. Gilles -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
Alexander E. Patrakov wrote: > 2008/3/19, Bruce Dubbs <[EMAIL PROTECTED]>: > >> My position is that we should stay with grup 0.97 and the compatible >> version of e2fsprogs until upstream gets the problems worked out. > > This doesn't work: GRUB has to be compatible not only with the LFS > version of e2fsprogs, but also with the hosts's version. We expect > GRUB to boot not only LFS, but also a host distro. If a host distro > uses a new ext3 filesystem, we have a big problem. What distros use the new version of e2fsprogs? What boot loader do those distro's use? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
On Wed, Mar 19, 2008 at 11:20:23AM -0500, Bruce Dubbs wrote: > My position is that we should stay with grup 0.97 and the compatible > version of e2fsprogs until upstream gets the problems worked out. That works great for booting LFS, but an LFS-installed grub won't be able to boot the host's kernel if that kernel is on a filesystem that grub can't read. (Moving on to the general issue now...) The real problem at this point (IMO of course) is that grub contains an FS driver of its own, for each FS, and grub updates so infrequently (if at all). If there was any hope of a new 0.98 version (with this patch included) soon, we could simply upgrade it at that point, but who knows how long it's going to take to get that out. (And of course, no new features will be accepted into grub ever, so if the grub people start to think that this is a new feature instead of a bugfix, it may never get released.) Since that's the problem, we could move in one of two directions to fix it: either stop using any filesystem driver in the bootloader (which means, at this point, "move to LILO"), or fix the ext2/3 driver in grub (with the patch). I don't think that the patch is that huge of a problem, myself. I'd certainly rather patch grub (for a while: until we get a new release, assuming that will actually happen) than have to deal with rerunning lilo every time I do anything with the kernel image. And then having to remember that I can't move the starting block of bzImage anymore either. (So /sbin/installkernel doesn't fix all of lilo's issues. It does help a lot, *if* you don't mind hiding the kernel installation procedure even more than it already is hidden, but it's not perfect.) Now yes, the same issues apply to grub's stage1 and stage1_5 files (and stage2 if no stage1_5 file is in use), but those get installed once and never change. I recompile the same kernel with different options built in (and overwrite its bzImage- file in /boot) from time to time; using an /sbin/installkernel script might help me with remembering to rerun lilo, but then modules_install target in the kernel will also be run, which will delete my module tree as well. And this will force me to reinstall nvidia and kqemu; today, I can simply overwrite bzImage and reboot. On the other hand, I can simply continue using grub and use the patch (i.e. deviate from the book), too. That's not great, but if the book moves to LILO, it will work. pgpE0dpCAXTwj.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/19, Bruce Dubbs <[EMAIL PROTECTED]>: > What distros use the new version of e2fsprogs? What boot loader do > those distro's use? Debian Lenny. It offers a choice among a patched version of Grub Legacy, LILO, and GRUB2. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Linux Foundation Collaboration Summit
I have been invited to attend the Linux Foundation Collaboration Summit taking place at the University of Texas Supercomputing Center in Austin, TX from April 8 to 10, 2008. I applied using my LFS background and feel I will be representing the community there. The agenda is at: https://www.linux-foundation.org/events/collaboration/program I will be attending the following sessions with LFS in mind: Open Source Legal Issues for Non Lawyers (do we want/need to change out license) LSB Workgroup Meeting (here I am interested in getting the directory layout updated. I don't thing /usr/X11R6 is really appropriate any more.) If anyone has issues that may be useful to address, please let me know. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
Bruce Dubbs wrote: > I have been invited to attend the Linux Foundation Collaboration Summit > taking place at the University of Texas Supercomputing Center in Austin, > TX from April 8 to 10, 2008. > > I applied using my LFS background and feel I will be representing the > community there. The agenda is at: > > https://www.linux-foundation.org/events/collaboration/program > > I will be attending the following sessions with LFS in mind: > > Open Source Legal Issues for Non Lawyers >(do we want/need to change out license) > > LSB Workgroup Meeting >(here I am interested in getting the directory layout updated. > I don't thing /usr/X11R6 is really appropriate any more.) There is more than just that holdover that is wrong the the FHS and with the LSB. [ at least in my opinion ] with the FHS: /media << new usrs think store music and videos, which is where MS stored them pre winxp, not removable disks / drives. This name is NOT clear and that lack does not help with adoption of GNU-Linux by more people. /mnt << if using /media, why bother with /mnt? if using /mnt then get rid of /media. 2 separate sections for mounting filesystems is a waste of effort. /opt << meant for third party applications, not those included in a distro? then why would any distro install anything into it? [ Suse, installs almost everything over the base system into it last time I checked to be specific. ] /proc << was this not being done away with in favour of /srv? With the LSB: Why would a BASE standrd not stop at the absolute minimum needed for a functioning system? The addition of package management [ for example ] to the LSB has made in no longer a BASE standard. If extras are going to be included, then call it a Linux DISTRO Standard, not a Base Standard. [ I for one ignore the LSB because it is not what it claims to be, a BASE for Linux.] LFS and DIY are much closer to being a base in the lack of extra software. Both sections need to be made as simple and clear as possible, with the absolute minimum required for a functional system to be base system standard. The additions to the LSB, while meant to promote support for Linux by commercial software houses, actually do nothing but polarize the community, since they pick one package over another, to the irritation of the supporters of the package(s) not picked. The infamous Vim / Emacs holy war being a good example of what the LSB is doing when they pick one package over another. A specific suggestion re the package manager, remove the reference to RPM in that section, and you remove the LSB from the dispute about which package manager is better. If the LSB just said packages must follow this format (format details as written, without reference to any specific package ) Anything that should be adopted by all distros must remain non-controversial to truly be acceptable by all, the more specific the LSB gets, the less respect many people will have for it. Specific in software over the true base system being the issue. Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
On Mar 19, 2008, at 1:52 PM, J. Greenlees wrote: With the LSB: Why would a BASE standrd not stop at the absolute minimum needed for a functioning system? The addition of package management [ for example ] to the LSB has made in no longer a BASE standard. If extras are going to be included, then call it a Linux DISTRO Standard, not a Base Standard. [ I for one ignore the LSB because it is not what it claims to be, a BASE for Linux.] LFS and DIY are much closer to being a base in the lack of extra software. I personally don't care if LFS is ever LSB compliant. While it would be nice to be "compatible" I'm probably never going to just download some installer script and run it with root privileges -- it just scares me too much. I also have trouble imagining a scenario where non- LSB-compliant LFS wouldn't pass management's muster, but LSB-compliant LFS would. That being said, I think some of your complaints about the LSB are unfair. Maybe I'm missing something, but the LSB Core specification is pretty sparse: http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/book1.html Obviously LFS wouldn't be able to apply the Desktop or other higher- level parts of the "full" LSB spec without a change in project direction, but the Core spec seems (to me at least) to have a reasonable scope. Both sections need to be made as simple and clear as possible, with the absolute minimum required for a functional system to be base system standard. The additions to the LSB, while meant to promote support for Linux by commercial software houses, actually do nothing but polarize the community, since they pick one package over another, to the irritation of the supporters of the package(s) not picked. The infamous Vim / Emacs holy war being a good example of what the LSB is doing when they pick one package over another. The LSB does not require specific packages. It is an interface specification, and any software that provides the prescribed interface would be considered compliant. The LSB goes to great lengths to define exactly which symbols must be provided by each library, with the intent of allowing higher-level software to run reliably even if the underlying software is swapped out. I realize that in some cases there is only one realistic contender for a "compliant" library, and that is potentially a cause for concern. But on the other hand there's nothing stopping related software projects from implementing the required methods and becoming compliant themselves -- OpenOffice seems to do just fine supplying both an OLE file interface and its own native interface. A specific suggestion re the package manager, remove the reference to RPM in that section, and you remove the LSB from the dispute about which package manager is better. If the LSB just said packages must follow this format (format details as written, without reference to any specific package ) Actually the LSB only says that compliant systems must be able to install RPMs. It does not say that compliant systems must use RPM internally, or even that the official rpm utility must be installed -- simply that packages in the RPM format must be installable. Moreover the LSB doesn't even require the entire RPM format spec, just a subset that's supposed to be moderately compatible. You can debate how "compatible" that subset is, but it seems to be working for Debian. Finally packages are only supposed to depend on the LSB specs, not on specific components, so you don't need to fill in the entire dependency tree. At least in theory you could just install the rpm utility, fake a couple of LSB packages into the dep tree, and call it a day. http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/swinstall.html Zach smime.p7s Description: S/MIME cryptographic signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
Zachary Kotlarek wrote: > > > Maybe I'm missing something, but the LSB Core specification is pretty > sparse: > http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/book1.html and that is where it should stop to be the base they intend. everything else makes it a DISTRO standard. LFS isn't a distro in the common meaning of the term, since it is not a collection of software pre-built and ready to go. compliancy to the LSB is, and should be, entirely up to the one building their system. Though including a link to the LSB and FHS in the book for those who want to build a compliant system is a good thing to do. I only use the FHS section, since having everything laid out the same helps anyone new to the host find their way around it. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
On Wednesday 19 March 2008 13:52:56 J. Greenlees wrote: > > Anything that should be adopted by all distros must remain > non-controversial to truly be acceptable by all, the more specific > the LSB gets, the less respect many people will have for it. Specific > in software over the true base system being the issue. > The LSB, to my mind, is too extensive. I share the concern over RPM. While RPM is not absolutely required by the LSB, it is quite clearly favored; this is a problem. I don't have the understanding to say whether other items in the LSB Core spec are needed/useful, but they certainly look extensive. The LSB Desktop spec is worse. Unless I'm reading it wrong, it -requires- the presence of GTK, Qt3, AND Qt4. This is antithetical to construction of a lean system. I understand the inclusion of selected fd.o specs and software, but this document simply goes to far. I see little need to go much further than the POSIX specification and the FHS. The FHS could do with some revision, but it at least tries to stay reasonable. -- Robert Daniels -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Vulnerability fixed in bzip2 1.0.5
Just for info: recently was fixed in bzip2 1.0.5. Description here: https://www.cert.fi/haavoittuvuudet/joint-advisory-archive-formats.html and fixed bzip2 1.0.5, http://www.bzip.org/ Bests, - ptr -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
On Wed, Mar 19, 2008 at 11:52 AM, J. Greenlees <[EMAIL PROTECTED]> wrote: > > With the LSB: > Why would a BASE standrd not stop at the absolute minimum needed for a > functioning system? The addition of package management [ for example ] > to the LSB has made in no longer a BASE standard. If extras are going to > be included, then call it a Linux DISTRO Standard, not a Base Standard. > [ I for one ignore the LSB because it is not what it claims to be, a > BASE for Linux.] LFS and DIY are much closer to being a base in the lack > of extra software. This isn't a proper channel for an LSB discussion, but the entire 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. 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. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
On Wed, Mar 19, 2008 at 12:23 PM, Robert Daniels <[EMAIL PROTECTED]> wrote: > On Wednesday 19 March 2008 13:52:56 J. Greenlees wrote: > > > > > > Anything that should be adopted by all distros must remain > > non-controversial to truly be acceptable by all, the more specific > > the LSB gets, the less respect many people will have for it. Specific > > in software over the true base system being the issue. > > > The LSB, to my mind, is too extensive. I share the concern over RPM. > While RPM is not absolutely required by the LSB, it is quite clearly > favored; this is a problem. I don't think it's true that RPM is favored. I believe RPM was just a fully implemented package manager used on more than a few systems at the time the LSB was written. See more background here: http://www.linux.com/feature/59502 > I don't have the understanding to say > whether other items in the LSB Core spec are needed/useful, but they > certainly look extensive. The LSB Desktop spec is worse. Unless I'm > reading it wrong, it -requires- the presence of GTK, Qt3, AND Qt4. > This is antithetical to construction of a lean system. I understand > the inclusion of selected fd.o specs and software, but this document > simply goes to far. I see little need to go much further than the > POSIX specification and the FHS. I think you're overlooking the purpose of the LSB. It has nothing to do with being a lean system. It has to do with providing a standard set of interfaces for 3rd parties to use. What if a company wants to provide a proprietary GUI app for their hardware? What toolkit are they allowed to use and have it work on Linux systems? If this doesn't sound like the kind of scenario you're interested in, then it's not worth trying to be LSB compliant. However, the need does exist, and there are definitely big players who would benefit from the LSB. Think about distributing your software that "works with RHEL x, RHEL y, SuSE z, ..." vs. "works with LSB 3.2.0". In the context of *LFS, I don't think it really makes any sense to pursue the LSB. I don't think anyone here has more than a curious interest in supporting these scenarios. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
Dan Nicholson wrote: > In the context of *LFS, I don't think it really makes any sense to > pursue the LSB. Yes it does make sense. It makes us a part of the larger Linux community. It enables a user to add a proprietary package if desired. I know many LFSers may not want to use proprietary software, but some do have occasion to use them. I, for instance, use both the NVidia drivers and VMware. They work fairly well with LFS, although both required compilation of kernel modules. I'm sure others use some proprietary or at least precompiled software like Java. If we weren't basically LSB compliant, we would be out on a far fringe. Do we need to make LFS perfect with respect to LSB? No. However, we need to be (and are) close. In some cases, perhaps some of our issues should be addressed in the FHS, rather than the other way around. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
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.) > 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. > 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. 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. Assuming the distro follows the FHS, they should install into standard locations when the user installs them as a dependency for the binary package. 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. -- Robert Daniels -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
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
