Ray> In article <m0uRSw8-000Lq4C@phascolarctid.rebellion.co.uk>
Ray> Jamie Lokier <jamie@rebellion.co.uk> wrote:
>> Come to think of it, this is probably best implemented in user
>> space. Use LD_PRELOAD to log the activity of system calls like
>> `open' and `rename',
Ray> I think I remember reading an announcement of a package to do
Ray> exactly this, not long ago on one of the c.o.l groups
Ray> somewhere. Came from someone at yggdrasil I think.
>> and perhaps rename or copy files that would be clobbered so that
>> the sequence can be unwound in the event of an error.
Ray> [...]
Ray> This is essential I think. Tracking files written during eg. a
Ray> "make install" is not really good enough - it may still clobber
Ray> other things without warning.
I don't understand this. Do you mean that the package may clobber
additional files after it has been installed, and that those should be
tracked as well?
Ray> Ideally you want a package manager with some kind of version
Ray> control system, so that "install package foo ; uninstall
Ray> package foo" is always a noop, even if foo overwrites some
Ray> files in package bar.
Absolutely.
Ray> For a "safe" make install you could perhaps use LD_PRELOAD to
Ray> redirect all writes to another part of the filesystem - and
Ray> then use the package manager to create/install the package from
Ray> that tree. Thinking about it, some filesystems (IFS ?) may be
Ray> able to do this or perhaps amd.
Yes, this would do. It is much harder than simply recording the
activity and making backups of clobbered files though.
Occasionally, your suggestion doesn't work as a few packages require to
be partially installed, then they run some of the new programs assuming
they're on the path, and then install the rest. `ncurses' is one such
package. Although this is very unclean, I would like to be able to
install free software with little thought beyond following the provided
installation instructions.
Ray> Currently I do this manually - for simple packages it's easy to
Ray> change the paths in the Makefile, complex ones usually use
Ray> either imake or GNU configure, both of which can be directed to
Ray> install in a different tree (using DESTDIR or prefix). I
Ray> normally do the make install as an unprivileged user as well -
Ray> which means manual fixing of ownership and any setuid/gid
Ray> afterwards (good in a way - forces you to check it).
That is still considerably more work then `./configure --prefix=/usr; make
CFLAGS=-O2', or whatever the package suggests. Even if you have scripts
to automate this, it will go wrong because some installation processes
are not clean enough to obey their own makefile variables.
I would prefer the package manager to notify me of setuid programs and
things outside the FSSTND. I prefer not to know about the safe stuff.
Ray> Once you have the package installed in it's own tree, it should
Ray> be trivial to make a "proper" package from it. The package
Ray> manager should then be able to at least warn you of any
Ray> conflicts with existing packages, allowing you to back these up
Ray> so the new package install is reversible (a pm that did this
Ray> automagically would be nice).
>> This appears, at first sight, simple enough that even I might
>> give it a go. Certainly I do hate putting together file lists by
>> hand when I install software.
BTW, I have put together a really basic LD_PRELOAD `rm' protector which
traps `unlink' calls, just to try the idea out. Logging program coming
soon perhaps (or not).
I would very much like to know of this Yggdrasil software, if anyone
cares to let me in on the secret...
Ray> Yikes ! Do people _really_ make file lists by hand ?
For every package I install, yes. This is very tedious, but is the
easiest way I know of (as yet) to keep track of what files are installed
by a package. It is a right pain ugrading even something as simple as
textutils-1.14 to textutils-1.17 this way though: I have to check how
many `textutils.info-*' files get made by `makeinfo'. Most packages are
not as clean as `textutils', and thus more work.
Of course, I hadn't heard of any decent package managers until very
recently, so I've been using my own scripts to look after things, and to
distribute packages to others on the local network. (My system is based
on Slackware 1.2)
I would _really_ like to be able to throw together an RPM for the next
alpha of some package in as long as it takes me to enter the right
compile and install commands. If the installation wanders outside
FSSTND, I can always check the file list afterwards.
Ramblings on and on,
-- Jamie