> Date: Thu, 03 Jan 2019 15:18:18 -0800 > From: Paul Rogers via blfs-support <[email protected]> > > This is all rather clear I'd've thought knowing pio's basic function.
Just to be clear: one does know how timestampers work - including what are their limitations: they have severe problems and should not be relied on for any rigourous work; they are naive 'toy's. You are claiming that pio works in situations where it does not work. > > > 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. Therefore, what you claimed in an earlier post - 'selling' pio to possibly unsuspecting users - is incorrect: for, pio does NOT reliably generate 'list of contents' for packages. Period. > If you need to include it, then simple enough: touch it in your build It is obvious that the pkgA/pkgB/certif1 example is for the general case - for the vast majority of packages - for which the user has not the prior knowledge that pio will FAIL for the item in question: and so the user does not know that pio has FAILed to do what its author claimed it can do reliably correctly; and so the user by default does not know to just adjust the cmmi for the particular item. JFC!. > 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! A genuinely dodgy site/js would EASILY fool you and your pio into believing like a happy idiot that all was ok. You and your tool would be easy meat for them. Surely you're not now advocating pio as useful in security work! > > 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 claimed that pio can create 'list of contents' for a package; and that those list-of-contents can be used for uninstallations. Both of your claims are BOGUS. And anyone relying on what you claim pio can do, risks data loss and disruption to software operation. As such, and if that is the standard that you and your pio are operating at, then the pio hint & related materials, should be withdrawn from the site. > > > > 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 You just don't get it. That only works if pio builds such lists correctly. And it does not build such lists correctly. > > > 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. No. You're absolutely wrong on that: either wilfully or unwittingly. > > > > > Perhaps 'successfully' insofar as perhaps unaware of 'unknown > > unknowns' ? > > Nope. I just learned how to use a timestamper properly. That said, the You don't know how to use a timestamper properly: at least, if your replies to the clear simple straightforward counterexample to your claims, are to be taken at face value. > proper use of any tool may take a bit of thought beforehand. > You don't understand the problem space: and as such are choosing an inappropriate tool for it. > > 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. You don't need to dump(-brain) every time pio is mentioned. > akh -- -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
