This is all rather clear I'd've thought knowing pio's basic function.
> It can be assumed in this example that only pkgA and pkgB have
> anything to do with '/etc/certs/certif1' : no other packages deal with
> it - either at cmmi or run-time &c - in any way.
>
> Does pio include '/etc/certs/certif1' in the 'list of contents'
> for pkgB ?
Since pkgB decided to NOT install the file, pio doesn't see any change
to the file's timestamp and does not record anything to do with pkgB.
If you need to include it, then simple enough: touch it in your build
script. I do that in my kern-build script to get the .config file
included in the backup.
It's not a mind reader. pio does not use a spec file. It doesn't care
what happened--it's usable even if no packages are being built--as I
suggested before, perhaps I'm testing a dodgy bit of javascript,
visiting a untrustworthy site, ANYTIME there may be file changes
between two points in time. That has its OWN uses!
That said, pio is NOT a configuration manager! The two are not the
same. If you need a configuration manager, use something designed to do
that. That's the Unix way.
> Alternatively, if '/etc/certs/certif1' does NOT get recorded in
> the 'list of contents' for pkgB, then consider the following
> subsequent steps.
>
> You want now to uninstall pkgA.
It did not exist prior to pkgA, so pkgA "owns" it. It's removal
script says: " rm -f /etc/certs/certif1"
It will be deleted when pkgA is removed.
If you touch it when pkgB is built, it's script says: "# rm -f
/etc/certs/certif1"
It will NOT be deleted when pkgB is removed. But since it was touched,
then if you'd backed up the pristine package files, restoring pkgB
restores the file, or preferably just using tar to restore the one file
in case other stuff had changed.
There is absolutely no reason to lose the file! It'd be your own fault.
>
> You use the pio-generated 'list of contents' for pkgA, to see what
> should be removed - BUT, *subject* to, for each item, it not appearing
> in the 'list of contents' for any other package.
# pio --xcheck pkgA
does the trick!
--xcheck PKG cross-check contents of PKG against all other
(executable) de-installation scripts to find out
whether a file has been installed more than once
> Now pkgB run-time complains or worse, because it's looking for
> '/etc/certs/certif1'; and the latter is now not present.
Only because you didn't understand how pio/timestampers work and apply
it properly.
>
> Perhaps 'successfully' insofar as perhaps unaware of 'unknown
> unknowns' ?
Nope. I just learned how to use a timestamper properly. That said, the
proper use of any tool may take a bit of thought beforehand.
And by the way, I've often built whole systems, using pio and loopback
"virtual" filesystems in a chroot. That way I can be doing other things
while pio is observing installations on what it perceives to be a "quiet
system" with nothing else going on. That's straightforward.
--
Paul Rogers
[email protected]
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
