> Date: Sun, 30 Dec 2018 10:04:27 -0800 > From: Paul Rogers via blfs-support <[email protected]> > > > > Have you seen "pio" the Package Installation Observer in the Hints? > > [...] > > > > > > [...] do a "make install", et seq., and I'll record what gets installed > > > [...] handy things are then possible, like searching through them to > > > see which package a particular file belongs to. > > > > > > > > > Sometimes o/c a package cmmi skips creation/&c of a particular > > '(path,type,contents,permissions,ownerships,...)' item, because it sees > > that such an item already exists: the latter may have come from > > an earlier version of the package, or from a different package, or > > somewhere else. > > > > > > Does pio list that the current cmmi package (joint-)owns that item ? > > > > > > akh > >
Am not sure if any of your below, addresses the question above. Could you clarify please what is the answer to the question? Thanks. I understand about removal/--help/&c&c (incl did go and read the script & related materials): but you say about listing of package contents; and I am not sure that it is not prone to getting it wrong. > > In the first place, I must run pio at the appropriate times, _generally_ in > my build scripts just before make install, or sometime before make, depending > on how the package builds itself, and again _generally_ after the following > configuration bits in the book are done. If some of those I deem > idiosyncratic to a particular system, they go into a different part of my > build script. > > In general characteristics, pio is a "time stamper" that compares "snapshots" > of given branches of the FS, ignore others (i.e. /var/log typically) at two > different times, then constructs a script that will remove whatever popped up. > > It really doesn't "care" or impose meaning on what just happened. Perhaps I > was planning to visit a dodgy website or use a dodgy javascript? > > Other functionality is added on. For example, immediately after I run it > the second time to get the removal script, I run its "backup" function that > tarballs those pristine files. > > As I already said, at this time I can also *tell it* what the package's > dependencies were, just so it will warn me if I try to remove any of them, > but with my OK it will do it anyhow. It never deletes a backup tarball! I > may be about to replace that dependency. pio can't know if it will "work", > of course, but when I removed it I had the option of removing that removal > script. I wouldn't in such a case. Then I install the replacement normally. > If it's a cockup upon testing, I can remove the replacement and restore the > original from the backup, none the worse for te attempt. > > Besides the normal "B depends on A", if A's only function is to support B, I > can *tell* pio it goes the other way too, "A supports B". That way if I > decide to dump B I can track down everything installed for it and remove them > too. All these things are just well-formed comments in the removal scripts > that can be grepped. But it's up to me to use them or not. > > To reiterate, pio's "attitude" is _NOT_ "I'll do all the package management > for you", but "I'll give you some basic tools to assit you doing package > management." I like that, because as your question suggests, sometimes it's > not such a simple task. And sometimes we have to think about how to control > it first. pio won't protect me from myself or my own misuse, but I really > don't want it to try! > > [10:01 ~]# pio --help [...] > (Please wrap your lines to max ~80 chars per b/lfs mailing-lists requested netiquette.) akh -- -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
