how will 'package-management' be implemented?

Reinhard bookreader at
Thu Apr 15 00:57:41 PDT 2004

On Wednesday 14 April 2004 23:44, Kevin P. Fleming wrote:
> Reinhard wrote:
> > So with BLFS, I checked the dependencies and sorted the packages upon
> > their dependency-graph (build from the dependencies from the book).
> > At package-ordering the level of the dependencies was also respected,
> > means, if the (end-)user choosed a package, wich is an optional
> > dependency of another package, the order will be changed to keep track of
> > that.
> >
> > This means, that a different entry to the profiles has to be generated.
> That's where I think we are differing; you are envisioning each user who
> wants to use a BLFS profile would use a tool to create their own
> customized profile from the BLFS book sources, where I am envisioning
> more of the current model where an already-built complete profile is
> downloaded and only the relevant parts are used (either manually or
> automatically).

Not really. When I started with the script it was just for me - an enduser of 
blfs. With time of developing and maturing (both, the script and me) I saw 
different types of usage.

The first usage was to create Makefile/shellscripts, which could serve to 
install the packages.
Next the script was extended to create profiles - but let me just declare some 
tokens to avoid verbal confusion.
An ALFS-profile is not just one file, but a bunch of files, one for each 
package and some more files to bring the package-files together and do 
additional jobs. 
When talking about "profiles", we mean the bunch of all related xml-files.
One package-specific file may be referred as sub-profile. Additional there 
exists "packages.ent" which contains all the package information and 
"general.ent" as some type of configuration and stil some other files.

> How would you propose an "automatically generated" profile would handle
> things like:
> - configuration entities (LFS build location, downloaded package tarball
> location, etc.)
> - package entities (tarball MD5/SHA-1 digests, etc.)

Well, that question shows, that you did not give the script a try.
Otherwise you would know, that the above items are already solved and working.

Of cause, you always need a part (configuration) that the enduser has to edit.
That's true for the official profiles and that's true for what my script 

If you would spent some minutes to try the script, you could see, what's 
already generated and what is missing. Then we would have a common base to 
talk about.

> I can't say for sure which is better, but I can say that having to
> download the book sources and whatever XML-related tools are needed to
> produce a profile from those sources would be a significant hurdle for
> many people who just want to have a working profile. I'm not saying that
> having the _ability_ to do that isn't useful, because it certainly is,
> I'm just saying that IMHO the users who would want to work that way
> would be in the minority.


Let me devide the profile-related-jobs, the script is able to perfom into 
minor steps:
1. extract the info out of the book
2. generate sub-profiles for each package
3. generate package-informations
4. generate maintenance steps
5. generate configuration stuff
6. generate the entry-file with package-order

Steps 1 - 5 are not necessary for the enduser, as they seldom are subject of 
change. These steps could be done once at releasing a new book-version.
The profiles could then be stored in cvs - like it is done today.

Step 6 is only important, if you work with BLFS. For LFS-variants this file 
could also be stored in the repository.

Step 6 for BLFS could be worked out, using the xml-book-version.
	Another way to do Step 6 is to use the sub-profiles.
State today, the script can extract the dependencies from the book and put 
them into the sub-profiles (in package-info).
So it's not important, how to perform this step.
Important is, that the step is performed by the enduser and that its result is 
a different entry-file for the (downloaded or otherwise created) subprofiles.
As the package-selection should work in interactive and non-interactive-mode 
you need a place to save the user-selection.
It is quite hard to impossible, choose packages just by name, if you don't 
know the package. Therefor I create a summary that consists of the 
package-name and a short description.
It's stil hard to do a selection with the short description if you don't know 
the packages.

Important for me is, that the book is the only knowledge-base, which needs 
human maintenance. All other things could be build from the book with one ore 
more intermediate/automated steps.

Just for completeness - why I think, using the xml-version of a book is 
apropiate for the enduser:
My intention for the script was:
- reduce the possibility of tipos
- reduce maintenance time (of the editors or profile maintainers)
- increase reliability

At no point I wanted to create a tool for dump "click and run" installation.

So I thought, the user would like to download the xml-sources and generate his 
own local html-copy. Just to read the book during installation steps.
I think it's quite necessary and acceptable for those, living at BE and only 
those may find my script useful.

Larry talks about his average user - and that user is intended to want to read 
the book.

I very hope, that the average ALFS-user is not a dump "click and run"-user, 
that does not like to read the book.
In that case, my script would be completely wrong.

Kind regards


More information about the alfs-discuss mailing list