From: David B. <dml...@gm...> - 2006-12-31 21:36:18
|
> I would solve this problem as follows: > 1. Provide a patched version of the package (similar to Gentoo) which > includes the DESTDIR variable used during installation, if DESTDIR > doesn't already exist. > 2. Install to a staging area using the DESTDIR environment variable. > 2. Copy the old package files out to an old version directory. > 3. Copy the new files in. > 4. Remove extra old files. > > The DESTDIR is found within most sane packages, or if not, should be > patched in. Why? these patches have to be done on a per package basis. There's an easier way of doing this without creating massive amounts of patches for every package or finding the right variable on a per build-system basis. Also DESTDIR is only gauranteed on an autoconf'ed package there are all kinds of other build systems out there, scons, ant, plain old make, python build systems, perl build systems and each build system does the DESTDIR differently. This ends up being tons of work for distros and honestly I'm tired of doing that kind of work. There is a transparent way of implementing this functionality using a fuse filesystem so that's what we're doing. Other distros don't do it this way and they don't have to, we just want to save ourselves a lot of work. > Well, it's a bigger security hole. The user simply creates his own mount > command, and the invocation of fusermount (which is typically installed > suid root), results in a root-cable program that can do just about > anything. So, it is important that fusermount NOT use the PATH > environment variable. I'm not discounting any security implications this might have. So I'm thinking there probably should be a better way than fork/exec to mount to get the entry into the mtab. It seems mount.c does the mtab entries manually, which means other unix-like systems probably do the same, and the mtab entries might be different. > >> Perhaps a configuration parameter for the configure script would be more > >> appropriate? > > > > This maybe the more appropriate course of action (I'm all about giving > > options to the user). > Based on your description above, it sounds like you'd need it to search > in more than one location, so this may not work. Possibly a > configuration parameter which specifies a few directories to look in for > mount would do. well, there's already an option surrounding the code on whether to update mtab at all, we may just have to turn that off perminantly for our users. - David Brown |