On 6/1/12 9:31 AM, James Robertson wrote: > Sure. Lets take sudo as an example. What could be considered a simple > program has 8 optional dependencies with 4 being "off book". I think we > ignore those 4 and worry only for the 4 "in book" optional > dependencies. The build instructions in the main BLFS book explicitly > use two without configure parameters to get around no pam or an mta. So > I am thinking we have a few versions of this package. > > sudo-1.8.4p4-book > sudo-1.8.4p4-pam-sendmail > sudo-1.8.4p4-pam-sendmail-kerberos-ldap > > The first notates that it is a package right from the book. The second > one adds pam and leverages a local sendmail and the third has all the > "in book" optional deps. The second and third packages would been a > pre- script to check for a valid sendmail command before installation as > well. > > The spec file for each of these will be slightly different and certainly > the run time deps will be as well. > > Lets use shadow as another example. Since shadow is also in LFS, there > is a real need for more than one version. > > shadow-4.1.5-lfsbook > shadow-4.1.5-blfsbook-pam-cracklib > > or something like that.
I have to admit that I didn't like this at first, because something like this would likely confuse auto-installers. For example, if we used pacman to auto-install a full base system to use as development - which version of shadow do we use? But after thinking on it some more, I think there are likely various ways to work around this and your multi-package method does fit the BLFS model more closely. > We you thinking of providing a pre-packaged kernel? That is going to be > an interesting one as we all love to customize our kernels. Present > company included. Yeah, not sure about this one. For pure (B)LFS development purposes, a packaged kernel isn't necessary at all. Perhaps we leave this as a 'build it and package it yourself' option for anyone that wants to actually use the binaries as a working system. I suppose we could still provide a template for it and let people generate their own config - the default perhaps being a very general purpose nearly-all-modules-enabled config. > I have been wanting to get back to contributing for some time and this > seems to be a great place to do it. I'm going to start by jumping on the parser, since it will be necessary right away for any of this to work. My initial thoughts are to build one parser that can accept different output filters, for example, outputting to PKGBUILD files, or rpm spec files, or even, the jhalfs-type build scriptlets. Any thoughts on that? JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
