Voilą!
Serge Caron wrote:
>
> >Let me reduce my confusion to its firstmost problem: How does your sed
> >process facilitate ``*I don't backup program binaries*''?
> >
> >AFAIK, ${pkg}.list files -- _minus_ ${pkg}.exclude.list files -- define
> >which files comprise the ${pkg} package -- correct?
> >
> >Once you eliminate all files under etc, /etc and ./etc from ${pkg}.list
> >files, what you have left is ``a bunch of binaries'' -- am I wrong?
> >
> >Wouldn't you reach this same end if all files under etc, /etc and ./etc
> >were only listed in ${pkg}.exclude.list files?
> >
> >Until I fully understand this premise of yours, I do not know how to
> >proceed . . .
>
> OK, so lets process this from the start. 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
>
> 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?
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?
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
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 ;<
Perhaps, this is a calling for creation of this file:
/var/lib/lrpkg/*.list
[2] Now, I must ask, again, how do you account for configuration files
that reside elsewhere, say /usr/share/snmp/snmpd.conf? 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''
> 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.
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.
> Now, by removing these lines, I can either backup these files in the default
> store (root.lrp if you are using Dachstein) or I could create a
> configuration package. If I did this, I could be missing out on other stuff.
> If I were to run on a hard disk, the persistent nature of the storage medium
> hides the problem: eveything you left will be there when you power the
> machine up again.
[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?
> 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 ;>
> 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!
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?
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?
[ snip ]
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
