> Date: Thu, 03 Jan 2019 10:30:54 +0000 > From: akhiezer via blfs-support <[email protected]> > > > 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 .
s/0600/0644/ > > 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 s/0600/0644/ > 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' ? > > > > > [...] > > > -- -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
