how will 'package-management' be implemented?

Reinhard bookreader at gmx.com
Wed Apr 14 14:27:54 PDT 2004


On Wednesday 14 April 2004 22:02, Kevin P. Fleming wrote:
> Reinhard wrote:
> > I personally would like to integrate the work in LFS land. AFAIK there's
> > no tools-section in LFS-land, so I would like the script to become part
> > of ALFS (my first choice), but others have to decide on that.
>
> I don't mean to be pessimistic, but I can tell you that this type of
> solution (a script that parses the XML) will always be less preferable
> to something that uses the XML natively (i.e. an XSL style sheet). 

That's not pessimistic - but realistic ;-)

> While I have not looked over your script in detail, I can see that it is  
> tied a little to intimately to the book's current state, and will require
> changes any time the book undergoes significant revisions. With an XSL
> style sheet, my hope is that this would no longer be necessary.

I'm not convinced, that your hope will fulfill.

I started with (a wrong concept) a pattern-machine with meta-info caught from 
the filename. That was good at first look (I only cared at the beginning for 
blfs), but failed with kde, gtk, ...

Then, with a trigger from discussion, I completely rewrote the xml-engine.
At that point, the "standard"-xml-engines could not parse the newxml and as 
the cvs-version often has an intermediate state, I did not want to fail on 
each error (like standard xml-engines do).

I already worked with standard-xml-engines like jakarta-commons-digester, wich 
enriches a xml-event-machine.
So I started my xml-engine in a similar way.
But then I realized, that it's not always possible, work out all states acting 
only on xpath. Therefor I changed the concept to do a kind of predictive 
parsing (like the one, used in state-machines).

This works fine, and I'm convinced, that I'm not tied too much to the 
book-internals.

The code for the BLFS-parsing is stil broken (I did not adjust it after 
rewriting of the engine), therefor I think, that's the reason, you think, I'm 
to tight to the book's internals.

I'm quite convinced, that if you change some of the internal structure of the 
book, you also have to rewrite any xsl-converters.
I don't know xsl, so I don't know, whether it is possible, to share code, do 
polymorphic function-calls, or other things I used in the script.

> However, I am also of the opinion that we will _always_ offer an
> up-to-date official profile, so there is not really any need for us to
> have a tool to generate a profile from the book sources. Think about it:
> if I want to do system build, would it be better to have to download the
> book sources and a tool to convert them into a profile, or just download
> the ready-to-run profile that is 1/5th the size?

No question, download the less the better.
But I stil believe, that it could be useful for the profile-maintainers.

Using BLFS-profiles changes the requirements to a build-tool dramatically.
Building LFS, it's quite *simple*, work in bookorder and it's fine.

With BLFS, the bookorder makes little to no sense at all.
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.

So the benefit of my tool could be, generating this entry each time, the 
(end-)user changes his selection.

After all, I'm stil convinced, that it would be the best way, to add all 
necessary information for profile-generation to the book(s).
Then with a job (no matter whether with my script or something different), the 
profiles could be generated and packaged for download.

Following your hint from the hackers-guide (moved from function to 
application) "do one thing and do that well", the package-selection and the 
generation of a build-order for the packages will stil be a job, performed by 
the (end-)user and - from my point of view - outside of nALFS.

This job could easily be a similar application with the same look-and-feel 
than nALFS, but I don't see the package-selection and package-ordering inside 
the profile-processing. It's quite a different step and that could easily 
produce a profile(-entry file), that could be processed by nALFS.

Kind regards


Reinhard




More information about the alfs-discuss mailing list