[lfs-dev] Once more: Package Management

James Robertson jwrober at gmail.com
Thu May 31 13:41:58 PDT 2012


On Sat, May 19, 2012 at 8:26 AM, Jeremy Huntwork <
jhuntwork at lightcubesolutions.com> wrote:

> I've been holding back bringing this up on-list for a while because I
> intended to do the bulk of the work and then present a working system to
> the community for comment and review. I still intend to do that, but
> given some recent discussions, I think the time is right to bring this
> up and see where it goes.
>

I have been watching this thread and it seems to have gone a bit dormant so
maybe now is a good time to add my thoughts.  First off -  Jeremy, your
contributions to this project continue to amaze me.  Keep it up buddy.

>
> (Sorry for the cross posting, but since it involves both projects, I
> wanted to make sure all saw it - if possible, please reply on lfs-dev.)
>
> Proposal:
>
> 1. Adjust LFS/BLFS to auto-generate build recipes for individual
> packages that a packaging tool can use to create binary packages with
> meta information included such as dependency tracking.
>
> 2. Store 'official' copies of those binary packages in a developer
> package repository so that when developing (primarily BLFS) a dev can
> automatically pull and install into a build environment the dependencies
> he needs to build and create an individual package.
>
> 3. Create a standard workflow and tools whereby a developer can
> accomplish #2 and edit the book accordingly in an efficient, reliable way.
>

OK so first let's make sure we are clear on goals, roles and
responsibilities here.  The thread seemed to float around a bit with some
concerns about losing the "roll your own" control that the books give us.

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

2.  PM is for book developers for the most part.  Support for the binary
packages and repository is to aid book developers. Non-book developers that
want to use the packages for their own purposes can do so at any time, but
the *-dev community does not support them for that purpose.

If we keep these things separate, we can add value for those that are
interested and reduce confusion and angst for those that are not.  I am
also thinking that if we leverage an "extension" of the main book sources
for the PM branch, then we can leverage jhalfs (after an enhancement) or
another parser to pulls the PM commands out of the book for rapid re-use.

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.

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.



> Rationale:
>
> (B)LFS-style development by hand becomes a huge undertaking. BLFS _is_ a
> huge undertaking - and it's a difficult beast to maintain. In order to
> create a stable reference page in BLFS an editor has to have spent the
> time to build all of LFS, tweak it, go through current BLFS, manually
> install dependency packages and then carefully document the package he
> builds. No two developers are guaranteed to have the same environment,
> either, so accuracy and stability becomes an issue.
>

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.


> The same is true of the LiveCD project, and is the main reason why it
> sits dead today. It is difficult to maintain when there are no packaged
> binaries to draw from and the entire thing is a scripted source build.
>

Which I would like to see revived and I think support of the binary
packages as part of a build script for the LiveCD would certainly help keep
it up to date.


>
> Let me just say now that because (B)LFS is primarily (and probably
> should always be) about educating, I don't think we should require
> end-users to use package management. Mainly the proposal is intended to
> assist in development. However, if we have taken the time to incorporate
> PM in our dev workflow, we can make the option of building via PM tools
> available to readers if they wish to use it for themselves and build
> their own package repository.
>
> Agreed, this is another reason why I am in favor of doing this in a
separate book.

[snip]

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.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20120531/6120c13b/attachment.html>


More information about the lfs-dev mailing list