releases and stuff
bet at rahul.net
Tue Nov 9 09:50:57 PST 2004
> On Tue, Nov 09, 2004 at 03:04:24PM +0000, Bennett Todd wrote:
> > And, as we've been discussing, it's appealing doing the entire
> > build as a non-priv user.
> As I was trying to point out, that can be done entirely without a
My apologies, I had missed that major and interesting point. I've
seen the issues of non-root build and destdir build conflated for so
long, always in the context of software packaging, that I'd lost
sight of the possibility that they could be independent. I should
have read more closely.
> But eventually we have to get to the following questions;
> 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, or some
database format that can be easily translated to XML. Hence,
whatever software packaging tool[s] (if any) we actually use, it
must be easy to robustly parse the master database; and hence, using
different software packaging engines is an easy, O(1) one-time
operation that works for all packages.
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.
From that point, taste can drive choice of packaging tool. I believe
the interesting candidates include rpm, dpkg, and portage among the
Big Players. I believe my bpm is very close to the simplest software
packaging tool that can meet the basic needs.
> Is this book primarily for building a hardened server, or teaching how
> to build a hardened server? (or where on the scale should we be?)
> What role do we take in teaching good admin *practices* versus teaching
> how to admin a box?
Nicely stated questions, and I think if the answers are nailed down
all the rest will fall out naturally.
> > It can also make it easier to partition work, maintaining individual
> > packages, perhaps by different people.
> Yes, but multiple admins is a highly debatable, highly personal, and
> highly advanced topic.
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).
> I know you are using it in context of supporting evidence, but
> I just wanted to throw out there for everyone that that is
> not something we should use as a means of justifying package
> management. It should be for us (i.e. the writers and readers)
> merely a possible enhancement gained by using package management.
I was proposing that use of software packaging, suitably integrated
with the book publication process, might make it easier to bring
more team manpower to bear on promptly updating the book each time
the next OpenSSL security bug set is announced.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the hlfs-dev