On 07/31/2010 08:08 PM, Kevin Buckley wrote: > On 1 August 2010 09:12, Bruce Dubbs <bruce.du...@gmail.com> wrote: > >> BTW, I once (IIRC around 2004) made a suggestion to scan the filesystem >> after each package and store information about each package's files in a >> DB. That kinda begs the question about how you get a db installed for >> use. We really don't want to install mysql in Chapter 5.
Berkeley DB could be done easily enough I think. > > Do you really need a DB though ? > >> Having a DB that has the history of every file on the system: what >> package, date, package version, filename, directory, would be useful. > > Could it not be a simple flat file listing ? > > find / -newer SOME_TIMESTAMP_FILE -ls > > where SOME_TIMESTAMP_FILE is touched after every package install > would seem to do all that one wants. > >> It's also well beyond what I think should be in LFS. If I ever actually >> implemented something like that, I'd write it up as a hint. >> >> -- Bruce > > There would seem to be an assumption there that the later package > additions, where they overwrite a file installed by an earlier package, > (because everything is done as root) are the versions of the file that > is the required one. Not exactly true. You very well may need to go back to a specific point in time. > One thing I found appealing about the Package-User hint and it's > methodology, was that such clashes were explicitly flagged whenever > a newer package tried to overwrite and existing file. > > It was then up the installer to decide what to do. > > It's not clear that use of DESTDIR, on it's own, would make that issue > any easier to sort out. > No, it is not covered in my version of the proposal. It wouldn't be terribly difficult to account for that however. The point of this exercise is to know what is being done. If you do run into a situation like that, then you'll know what to do about it, ie: reciprocal dependencies within the binary package. There is a lot of learning to be gained by introducing DESTDIR. I actually hadn't thought of that one WRT only LFS for the scope. > What one would appear to need to do is to go down the PkgSrc route > where one creates a list of files after the DESTDIR install which can then > be altered so as not to overwrite existing files in the install proper by > virtue > of inspecting the DESTDIR installtion against the file in the live system > and removing those which should not be overwritten by that package's > version. > But then one is installing against an existing list of files which seems > to complicate matters in that you either have to trust someone who > created the list ahead of your install or jump through a couple more > hoops when installing yourself. > > Then again, maybe that "trust" is no more than that afforded to the > writers of the install commands in the *LFS books? This is true, but it is also already accounted for in LFS. For instance, the man-pages package is installed very early in chapter 6. This is because all the package specific man pages are assumed to be newer than the ones in the man-pages package. Of course, situations like that should be dealt with by removing those files before installation, and introducing a reciprocal dependency in your packaging system. If you work with a full blown PM, then you know where every file comes from, conflicts are simply not allowed. This is one of those situations where install logging fails us, unless you account for it after the fact. I do so by grepping through the entire log directory for each file that is "newer" and prepend (M) in my logs. In some cases, I've have files like /usr/share/info/dir that have 200 (M)s in front of them (because I had forgotten not to include that file in my excludes for my package logging tool). It also goes without saying that I cannot make binary packages from my completed system by using this method, whereas, if everything were properly accounted for, prior to installation, I could. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
