On Thu, May 31, 2012 at 5:40 PM, Jeremy Huntwork <
jhuntw...@lightcubesolutions.com> wrote:
> On 5/31/12 4:41 PM, James Robertson wrote:
>
> > 1. Adding PM is NOT a replacement for the books. It should also be
> > noted and clear that the purpose of this effort is not to turn (B)LFS
> > into a binary distro. It is and always should be a cookbook so those
> > that want can still roll their own. I really think that this effort
> > should be a book development tool and cookbook for those wanting to
> > learn about package management. I think the current books stay as is
> > and PM is another off-shoot like cLFS. The books should stay
> > independent as they have different goals. I am thinking that we attempt
> > to leverage the (B)LFS book sources in some manner (maybe combine them
> > into a super book) and then add the PM stuff to each page (build
> > steps). If we go this route, we won't confuse goals and won't make the
> > main books too hard to read. Remember we get new users all the time.
> > Also by creating an off-shoot version of each book, we can go hog wild
> > with educational text about package management strategies, procedures,
> > etc and that text stays out of the main books (again because it is not
> > the main book's goal).
>
> Hmm, possibly. I'm wary of new projects/books (given their life span)
> but I also see the value in what you're saying about keeping the book
> unchanged.
>
I understand. I think the value is greater however than attempting to put
what all I can see us wanting to put into this into the main books.
>
> > Questions about the binary repository came up. I too have some
> > questions about that. What is the definition of 'official'? Who/What
> > is 'official'? Who is going to vet submitted binaries? What is the
> > standard we are going to follow? I would assume binaries compiled with
> > commands right out of the books with no extra optimization flags and
> > such, but that should be agreed upon. Yet another good reason for PM to
> > be a separate book. We can have a whole chapter documenting this if we
> > need to.
>
> Yep, all good questions. I don't know the answer yet. Perhaps the answer
> is to do like I suggested in another message and show a proof of concept
> first, then we can tackle the hard decisions as the concept gains ground.
>
Yes, I definitely think a poc is in order. Like many things, "if you build
it, they will come" plays out nicely. I honestly think that a combined
"super book" that leverages the build page source from each book is the
best approach. That way we don't have to re-type (CnP) the main book
source steps into the PM cookbook and then can add PM specific items like
you suggested we add into the main books there. I am not sure how to do
this exactly, but if we can figure it out it would make development of the
book easier. We could then take some advantage of a single book and insert
optional steps in from BLFS that make sense and also not have the direct
break between books as the purpose is really to work with both to aid
development.
>
> > The separate work things also aid #3 above as well. We can document the
> > standard workflow, tool use, etc there. Things like what you need to
> > get started building a book development environment, a reminder of
> > selection criteria used for the PM tool of our choice (just to help us
> > remember why a certain tool was picked as our memory fades), etc. One
> > tool I think we will need is a spec file generator. This goes back to
> > my thought about putting xml tags in the book source that is parsed out.
>
> Yep, the parser/generator will need to be one of the first things tackled.
>
> > WRT BLFS book development specifically. Lots of commentary about
> > dependencies - both build and run-time ones. Part of the PM project
> > would be to standardize how we create packages. My thinking is to
> > create a package for the required deps and the come up with a way to
> > generate other "versions" of a package with the run time deps built
> > in. Keeping PM in a separate book will give us this option to document
> > and explain.
>
> Not sure I'm following this exactly. Do you mind being a little more
> specific or provide an example?
>
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.
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.
> > I would like to contribute to this one, but won't be able to until this
> > fall when I can get some other things off my plate. Never seems to be
> > enough time to do what I want to do.
>
> Nice! Totally understood. We're all busy... some perhaps more than
> others. :) I look forward to working with you on it.
>
> JH
> -- <http://linuxfromscratch.org/mailman/listinfo/lfs-dev>
>
I have been wanting to get back to contributing for some time and this
seems to be a great place to do it.
James
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
