-----Original Message-----
From: Michael D. Schleif <[EMAIL PROTECTED]>
To: Serge Caron <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: February 14, 2002 6:20 PM
Subject: Re: [Leaf-devel] Re: Standards and due process :-)
>
>Voilą!
>
[snip]
>> Only concentrate on those two etc entries. The package author did not
define
>> a .local file to backup just part of the package. The package is running
off
>> CD and I can't rewrite it there :-). Finally, even if I could, I DO NOT
WANT
>> to. I want to keep this package in whatever form it was delivered for the
>> entire duration of its useful life.
>
>OK, now I see! Somehow, if you explicitly stated this before, I cannot
>find it in your previous posts. Dear me, I am too literal, again ;<
>
>Actually, I faced this same dilemma many months ago; but, I conquered it
>in quite a different manner -- I keep my own DCD development tree and
>have finely tuned *ALL* LIST and LOCAL files to my particular needs. In
>fact, now that I have successfully attained a leaf developer site, I
>have been thinking about publishing what I believe to be the correct
>LIST and LOCAL files for those packages included in DCD and those else
>that I use. Is this a case for convention and standards, or is
>willy-nilly construction of these files adequate to the task?
>
OK. You build /var/lib/lrpkg/xyz.local files with your choice of files that
have dynamic contents and should be included in a partial backup and your
choice of files that have static contents (tables, binaries, ...) and should
only be included in a full backup. Then you use lrcfg (or some other tool)
to specify for each package wheter you want a partial or a full backup.
Finally, you also specify, per package, the destination device.
So, if you run 10 packages on CD, you may end up with 7 partial packages on
floppy. This is Charles design and there is NOTHING wrong with it.
>Your process has the added benefit of placing *ALL* LIST elements in one
>(1) file -- something I have on my todo list; but, have not taken time
>to achieve, especially in light of Charles' musings on redoing the
>entire package thingy anyway. O, that is what we are discussing, huh?
>
My process, as you put it, is simply to dis-associate some files with the
original package they came from. One of the difficulty in LRP is that you
CANNOT have exact same file name in two different packages. Both packages
will load, the last one overwritting the first one. If you backup either
package, the file is dropped because the filelist of one package is the
exclusion list of the second one.
Breaking this association removes the difficulty entirely. I can then, if I
want to, backup to whole lot in package gizmo.lrp if that is what I fancy.
>Two (2) questions, at this point:
>
>[1] The *only* way to make your ${pkg}.list modifications stick is to
>perform a backup -- right? Since your example, bindc.lrp, includes *NO*
>LIST file and you have no time to create one, then you need to backup
Oops! Did I go wrong somewhere? Here is what I sent you: "Here is the
contents of
/var/lib/lrpkg/bindc.list, an old BIND 8.something package:
etc/init.d/bind
etc/named.conf
usr/sbin/named
usr/sbin/ndc
var/lib/lrpkg/bindc.*
var/named
"
Since the contents of /var/lib/lrpkg/bindc.list is explicitly listed, there
is a LIST file.
>the *entire* package, just to enforce persistence of this modification
>-- right? If so, what do you gain? Hopefully, it is not a large
>package, nor that you have only that floppy on which to store it ;<
If I modify the contents of the list file and I were to do a backup, then I
would loose some contents of the original package. However, I am explicit in
giving the example that I run from a CD (I would prefer ROM :) and that,
regardless of the storage media, I do NOT want to modify the original
package. In other words, there are packages for which I will never backup.
>
>Perhaps, this is a calling for creation of this file:
>
> /var/lib/lrpkg/*.list
>
The file is already there, per above.
>[2] Now, I must ask, again, how do you account for configuration files
>that reside elsewhere, say ? It seems to me
>that exceptions -- remember, the more the merrier! -- are quite costly
>and speak loudly in support of those issues that I take with your
>previous statement:
>
> ``there should not be a baseline specification''
I gave as an example a code snippet for /etc from a rather specific machine
down the hall for which we wanted write-protection at all times. Again, my
personnal experience with LEAF/LRP is that there will be new dynamic
contents every time you introduce a new package in a configuration. Your
package likes /usr/share/snmp/snmpd.conf and BIND likes /var/named. /etc is
easier to do than /usr.
To be specific, if a package maintains dynamic contents in /usr/sbin then I
HAVE to backup the original package (full or partial). However, I currently
do not run such packages and, I my experience, most package developers have
behaved. Do you have a different experience?
>
>> Once the package is LOADED, I delete the two etc lines from the list.
This
>> means that any other package can now claim these two files. If these
files
>> were enumerated in, say, /var/lib/lrpkg/bindc.exclude.list, they would be
>> excluded from every other package AND bindc.lrp. This is important,
please
>> stop here if it is not clear.
>
>Yes, good point. Nevertheless, this is, perhaps, the most pernicious
>flaw in the current system.
>
OK.
>Did anybody say that the current system is perfect? Notwithstanding,
>the convention-al, standard-ness to its essence? No, I am not flaming
>the current system, nor any part thereof; rather, it is this learning
>process that begs for elucidation, regardless whether or not you like
>the terms 'convention' and 'standards'! If the current system changes
>-- I guarantee that it will -- the convention is to publish those
>changes to the user community, such that users of the system can use the
>system in the proscribed manner.
I do not remember being critical of the current system. What I AM saying is
that there is no obligation to store a file in a given package. First, there
is no obligation to have the default store in the initial ramdisk. Second, I
may want to backup more thant what the package developer had intended.
Third, I may not have a choice of conventions because packages like the
ISC's dhcpcd will store their stuff in /var/state and pppd will store its
stuff in /etc/ppp: I am in no position to rewrite history and these
conventions exist outside of LEAF.
You are correct in saying that we don't have to make matters worse. However,
it would be a problem to fault someone dealing with dhcpcd to store
transient data in /var/state rather than /tmp, for example.
You are also correct in saying that there is a burden on the shoulders of
the person assembling the system. Do you have a suggestion?
[snip]
>
>[1] If they reside in root.lrp -- *always* the FIRST package loaded! --
>then, your laziness in not creating bindc.list bites you in the a**,
>because bindc.lrp just over-wrote your precious configuration files!
>
>[2] If you are going to ``create a configuration package'', then why
>bother with this kludge at all? Why not build a better mousetrap and be
>done with it?
>
[ out of sequence ]
>> Dachstein loads the default store BEFORE anything else and this is not
>> helping your understanding. If etc/named.conf is in both root.lrp and
>> bindc.lrp, the later MUST overwrite the former because the package
loading
>> code is in root.lrp. By separating the default store from the boot
loading
>> code, you can load the default store in the order YOU chose :-) Cool!
Leave my a** alone! ;-) I know that working from concepts alone is difficult
and that your logic is based in part on the tools you have at hand. However,
you have a better mousetrap on the floppy discussion.img.
>> What I want is the entire contents of etc (and other stuff) as if I was
>> working with persistent storage without affecting each package.
>
>Yes, we all do -- at minimum cost. Your offer to ``create a
>configuration package'' is looking better and better ;>
>
Thank you.
>
>The question, then, becomes: How do we ``load the default store in the
>order YOU chose''? Although, I probably missed this, also in my initial
>confusion; please, be so kind as to reiterate?
>
OK. To make a long story short, the contents of the initial ramdisk is
explicitly and unambiguously enumerated in a package list, LEAF.list in the
case of the discussion.img floppy. This precludes the inclusion of / by
definition. / is part of a different package, root.lrp in the case of the
discussion.img floppy. root.lrp being just another package can be placed
anywhere in the LRP=blah,blah,root,blah,blah load sequence. You type, you
choose TM :)
>As your theses become clearer, I am left wondering what I have missed
>earlier in discourse. Can you point me to earlier posts in which my
>questions are answered?
>
I am waiting for a plane and cannot do that right now. I suggest you visit
http://leaf.sourceforge.net/devel/scaron/leaf.htm with a fresh eye and mess
around with the discussion.img floppy.
Please take apart root.lrp before you start (just for fun!). If I remember
correctly, the floppy is designed to loose klogd if you backup root before
you edit /bin/busybox.links to remove the line /sbin/klogd. So you can
experiment either way. Don't flame me if it's too simple :-)
Regards,
Serge Caron
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
