lkml.org 
[lkml]   [1996]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: packages and not the kernel
Date
Quoth Albert Cahalan:
>
> From: Michel LESPINASSE <walken@via.ecp.fr>
> > When someone switches to a unix environment and starts to administrate
> > it, the way packages are organized always seems strange to him at first.
> > I can remember when I was a starter, and I always asked myself why some
> > package has to be divided into several directoryes - ie
> > /usr/local/bin/prog, /usr/local/man/man<n>/prog, /usr/local/lib/whatever.
> >
> > Now that I'm a bit more experienced with this and that I've read the
> > fsstdn and so on, I realise that the value of this organisation. but
> > still, I'm not fully satisfied with it. It still lacks some features that
> > would be really useful in everyday's life.
>
> > Basically I would like to be able to type something like "setpackage
> > libc-5.3.18" before my make install or my tar xvzopf, and the kernel
> > would remember for me that any new files it creates are part of this
> > package. This would allow for a much more generalistic solution.
>
> No way.

Why not? (Excuse my wooky shell scripting; this is just concept)

#!/bin/bash
# setpackage - starts package accumulation
# usage: package-name
# jhp 1Jun96

mkdir /var/adm/package-times 2>/dev/null
touch /var/adm/package-times/$1.start

then unpack your files. End with...

#!/bin/bash
# endpackage - ends package accumulation
# usage: package-name
# jhp 1Jun96

touch /var/adm/package-times/$1.end

Now that you've done all that, you can run this little script a few times
underneath different directories to get a list of files that have been
touched or created...

#!/bin/bash
# listpackage - list package contents
# usage: package-name directory
# jhp 1Jun96

cd /var/adm/package-times
find $2 -cnewer $1.start ! -cnewer $1.end -print
echo .
find $2 -newer $1.start ! -newer $1.end -print

which will produce the list of files created under a certain directory
between setpackage and endpackage, followed by a ., followed by all the
files modified in that span of time. (Modified files are important to watch
for so that you know what config files your install just put itself into.)

(This desperately needs some manual or perl post-processing, but I'm
certainly not up to automating it.)

Bad news: Many other files may have been modified in the timespan between
setpackage and endpackage. Of course, you'll select your surveillance paths
carefully (avoiding /home and /tmp, mainly), including /bin, /sbin, /etc,
/usr (no one said it had to be fast =:^) ) and perhaps a few others.

Also, without a journaling filesystem, you can't undo changes to config
files. Soft links may also pose a bit of a problem as to checking for
uniqueness.


Followups to linux-admin (as this really _isn't_ a kernel issue, and
probably should not be).

-jhp

--
Jon Pickard * 149 Olive #45 * Paso Robles CA 93446 * +1 805 2399518 * 6372F5B9


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.074 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site