> Date: Mon, 31 Dec 2018 15:51:01 -0800 > From: Paul Rogers via blfs-support <[email protected]> > > > > > 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. > > > > Perhaps I don't understand your question,
It's a straightforward question about a straightforwardly well-understood scenario. Here's a more-detailed example: == You want to install a package called 'pkgA' . - pkgA run-time can use security-certificates. - pkgA cmmi by default will install a bunch of certs if/as required: and in particular if not already present in the target os/install area. You don't have any version of pkgA installed currently. There is no path '/etc/certs/certif1' present in the target os/install area. pkgA's cmmi creates, in the target os/install area, the file (w/ perms/owns/ts) : 0644 root root '2018-12-28 19:33:31.824755350 +0000' /etc/certs/certif1 Pio records all-OK that '/etc/certs/certif1' is in the 'list of contents' for pkgA. Now you want to install pkgB. - pkgB and pkgA are separate independent pkgs from each other. - you don't have any version of pkgB installed currently. For pkgB, like pkgA: - run-time can use security-certificates. - cmmi by default will install a bunch of certs if/as required: and in particular if not already present in the target os/install area. In particular, pkgB config/make will build ./certif1 : and the 'make install' stage would by default - i.e. in the absence of any '/etc/certs/certif1' already in target os/install area - install it to '/etc/certs/certif1' and with perms/&c 0600 root root type=file . But pkgB is careful to not simply clobber existing objects in target os/install area: if an intended target-path exists already, then pkgB's cmmi will do some comparisons between its own config/build item and the already-existing item in target os/install area; and act accordingly. In this present example, pkgB sees that its own config/build item './certif1' is identical in content to the already-existing (from pkgA) '/etc/certs/certif1': and, pkgB is ok with the 'perms/&c 0600 root root type=file' that pkgA has already applied to '/etc/certs/certif1' . So pkgB decides to not bother with an 'install ...' command for its own config/build item './certif1' . And, pkgB has at no time caused the '2018-12-28 19:33:31.824755350 +0000' timestamp, of /etc/certs/certif1, to change. pkgB completes its install all-ok. And the timestamp of /etc/certs/certif1 is still at the '2018-12-28 19:33:31.824755350 +0000' that pio recorded for pkgA. Pio records various things about the installation of pkgB. 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 ? If 'yes', then how does it do it, if the timestamp has not changed ? 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. 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. In the 'list of contents' for pkgA, there is the item '/etc/certs/certif1' . And said item does not appear in the 'list of contents' for any other package. So you go ahead and remove '/etc/certs/certif1', as part of removal of pkgA. Now pkgB run-time complains or worse, because it's looking for '/etc/certs/certif1'; and the latter is now not present. == > or you haven't considered the way a timestamper works. Timestampers are > simple, very Unix-like. ;-) pio is nothing as ambitious as any of the major > distros' package managers. It doesn't "build" anything, doesn't want to know > how! All it knows is what files were added, removed, or touched between two > points in time. Turns out, that is enough, if used properly. pio won't save > one from oneself! One has to be orderly. > > "...earlier versions of the package..." Not a problem, remove them first, > don't overlay. For example, if you want to upgrade nano-2.0.6 to 2.3.2, you > create a new build script with your existing nano, remove 2.0.6 and install > 2.3.2, clean. If 2.3.2 blows up, remove it and restore 2.0.6, as you were. > Have your own special nanorc you want to use, install it when pio isn't > watching. pio should only be watching the default package builds. > > The one place where I allow any overlays is in kernel customizations. My > kern-build script appends the version number to the kernel directory name and > gives that to pio as the name of what is being built. So if I'm trying to > get a kernel I like and I make *-5, try it, decide I don't like it, -4, or > -3, I remove -5, restore -4, remove -4, restore -3, remove -3, restore -2, > backing everything out step by step as it got made. Then I can start from -2 > to try a different approach to -3. But remember, pio never deleted any of > those three backups I made. When I tell it to backup the new -3, it asks if > I want to overwrite the one already there. Yes. -4 & -5 are now from a > branch that got sawed off, so they should be deleted by hand. But in a wierd > emergency, I could run tar on one and get some kind of kernel back. > > pio does know an existing file was touched--it saw the file's timestamp > changed--that's what a timestamper does. In the removal script that goes as > "# rm -f filename", so it isn't removed with the rest of the package--"It > isn't 'mine'". It's content could have changed, but pio doesn't know or > care. pio doesn't diff--that's not what a timestamper does. But if one runs > backups of every package as installed, as one certainly should, then once one > examines the situation, one can run tar to restore just that one file. (I > examined if it was feasible to automatically restore changed files and > decided it's not. Circular unchanges are possible.) > > pio works, if one understands how, and uses it in a manner that lets it see > what the proper state of installation is. > > > > > 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. > > > > I've been using it successfully since LFS-4.1. What more can I say? Perhaps 'successfully' insofar as perhaps unaware of 'unknown unknowns' ? > [...] > akh -- -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
