releases and stuff

Archaic archaic at linuxfromscratch.org
Tue Nov 9 10:16:04 PST 2004


On Tue, Nov 09, 2004 at 05:50:57PM +0000, Bennett Todd wrote:
> 
> My apologies, I had missed that major and interesting point.

It is powerful, but can get hairy, as can destdir, with certain
packages.

> > What do we use for a package manager?
> 
> I think _that_ one isn't too terribly hard to answer.
> 
> Since the primary focus of the *LFS projects are _books_, the
> primary software packaging database must either be XML

I actually lean more to the side of no package manager as that brings in
more packages, more deps, more hassle, and possibly more points of
breach. I would not care to have a full set of xml parsers/processors in
my default build. Just my opinion, though. However, I have studied bpm
and as far as package managers go, I do like it best. However, I don't
particularly subscribe to the notion of PM's saving time unless someone
else did all the work.

For instance, let's say I (personally) want to install ssh on a server
that does not have openssl. I have an identical install of that server
at home with the full development necessities, so I build ssh and it
fails on ssl. I build ssl and then ssh, make a note on the buildscript
for ssh and I'm done. I don't have to encapsulate that info into some
cryptic non-human language form to know ssl is needed. At the same time,
I have chosen (once) exactly what features I want and also noted them.
Now, I don't need an outside PM and the package was built how I want. I
then tar up the results (minus includes and the like) and have a package
that works great on my highly personalized servers. Now, when a new ssh
comes out requiring a highly specific version of ssl, I don't have to
code in a bunch of versioning logic. I just have to note it. Of course,
this is all predicated on one premise; a server should never have so
many packages that this method becomes an unruly burden.

> I would suggest that _if_ the following questions end up with
> answers suggesting we should actually think about packaging at all,
> the master database format will want to be something like XML or
> OGDL or some other very well-defined, easy-to-parse structured data
> format, and that we'll want to have as small a collection of
> required fixed fields as suffices to meet our immediate needs.

That I agree on totally. Either way, I believe that if we ever go that
route, we need to at least have a useable book defining a base system
first. Otherwise, it is all still smoke and mirrors.

> Nicely stated questions, and I think if the answers are nailed down
> all the rest will fall out naturally.

I don't share your optimism. :) I don't think those questions need to be
asked constantly because I don't think they can ever be fully defined to
the point that they apply across the board. At least, not until much
time has passed, and many iterations of asking and answering have
happened. :)

> I was talking about actually maintaining HLFS itself. The master,
> published reference should be pretty aggressive about updating. We
> probably can't get away with a build that completely omits openssl,
> for instance, and once you buy in to openssl you really need to be
> aggressive about updating it (and, if you statically link like I do,
> rebuilding everything that links it in).

Yes, that has many valuable aspects and that knowledge should be made
publicly available. Good point. I hadn't looked at it from that angle.


-- 
Archaic

It will be of little avail to the people, that the laws are made by men
of their own choice, if the laws be so voluminous that they cannot be
read, or so incoherent that they cannot be understood; if they be
repealed or revised before they are promulgated, or undergo such
incessant changes that no man, who knows what the law is to-day, can
guess what it will be to-morrow. Law is defined to be a rule of action;
but how can that be a rule, which is little known, and less fixed?

- James Madison, Federalist Papers 62




More information about the hlfs-dev mailing list