Yet another LPM

Robert Connolly robert at linuxfromscratch.org
Thu Mar 29 06:33:41 PDT 2007


On Thursday March 29 2007 06:47, Jan Dvořák wrote:
> Hi,
>
> 	one of bullets on Robert's TODO list was:
>  > It'd be nice to catalog new files as each package is installed, with
>  > a find(1) script or something similar, and maybe toss in md5sum too.
>  > So if two packages install the same file we know about it.. so we know
>  > whether /usr/share/man/man1/su.1 is from Coreutils, Util-linux,
>  > Shadow, or something else. It'd also be usefull for tripwire-like
>  > setups, and a foundation for package management (automated or
>  > otherwise).
>
> 	IF it is acceptable, that the main dependencies are UnionFS and FUSE,
> then http://jh.gvn.cz/~jd870911/lpm/ may help. It is somewhat similar to
> Slackware's package management. The script `lpmb' uses tiny FUSE wrapper
> `monofs' to make whole system look like one file system (no need to care
> about /usr not being in place anymore) and then overlays the view
> (real-only) with UnionFS, creates temporary work directory in /tmp
> (after `mount --bind /tmp` for speedup) and chroots into overlay.

An index file for package management is just a side effect, not the goal. I 
think a UnionFS system would be overkill.

Off the top of my head I'm thinking something like this:

find / -wholename '/sources' -prune -o \
	-wholename '/etc/index' -prune -o -print > /etc/index/base.list
# Install man-pages
find / -wholename '/sources' -prune -o \
	-wholename '/etc/index' -prune -o -print > /etc/index/total.txt
#
diff /etc/index/base.list /etc/index/total.txt > /etc/index/man-pages.list

I'm not sure how well this works when a package is reinstalled or upgraded.

There's an Mtree program that does something like this but the output of Mtree 
isn't as easy to read as Find's, and Mtree isn't as flexable as Find. It's 
pretty easy to add an -exec option to run sha1sum, or gpg if you want to get 
nuts. Find's -ls option prints the inode, timestamp, ownership, size, and I 
don't know what the other (second) field is. The only thing I see Mtree doing 
more is giving file type, although file(1) can do that with the -exec option 
but not as quickly as Mtree.

The diff's would need to be searched for <>'s going in the wrong direction, 
indicating that a file was replaced by another package.

OpenSSL can encrypt the index files to secure them for a tripwire.

It shouldn't be hard to work with these index's to make them work with any 
package manager, if desired. Your UnionFS idea and this indexing idea could 
work together, with or without some modifications.

The purpose is to know which files came from which package so everything is 
accounted for, and what their attributes (ownership, size, checksum) are 
supposed to be, while not inhibiting us from doing more with it (like mtree 
does).

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20070329/bd28d112/attachment.sig>


More information about the hlfs-dev mailing list