On Sat, 5 May 2001 16:48:05 -0400 Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote: > > > maybe it is a stupid question, but can debian packages be installed in other > > places than / ? > > > > I know that when the package is compiled the Makefile has a $DESTDIR > > attribute, but is this preserved in the deb package? > > > > This issue came up when i tried to convince someone that debian packages > > are a good addition to tar.gz for distribution... but one argument he gave, > > was the question if non-root users could install debian packages? > > > > Is this possible? > > Debian packages require root privileges for installation. While you could > unpack a .deb in your home directory and use the files in it, you would lose > most of the advantages of using a packaging system (file tracking, > autoconfiguration, etc.). If you use it this way, a .deb is no better than a > .tar with binaries in it. > > I suppose you could install most simple .debs in a chroot environment where you > owned everything, but many packages (notably those which run daemons, cron > jobs, etc.) expect to be able to perform tasks as root. > > That said, .debs _are_ a good addition to .tar.gz for distribution. This is > what Debian developers (in general) do: create and distribute .debs. One could use fakeroot to create a sort of virtual machine, in which regular users can install packages as they please, but fakeroot doesn't support chroot (yet?), and I'm beginning to think a better solution would be an operating system within an operating system, and let the user play in her `own' system, and while it for all intents and purposes seems to be running on bare metal, it really is a virtual machine. That would be quite fantastic for doing normally privileged operations without a security risk, though. This could also be useful for Debian developers. This way, they could not only develop their packages on Debian machines (on which they don't have root), but also test them. I imagine quite a few packaging bugs in unstable would be wiped out that way. ;) For that to work, you'd also need to set up a base system for each and every developer. That would waste a lot of disk space in a hurry. Perhaps copy-on-write file links would do the trick here, allowing root to keep a central repository of a prototypical base system, and allowing each developer to change it at will, but without wasting disk space unless something actually changes. Of course, that means big changes in the kernel's VFS code and possibly elsewhere, but copy-on-write links would be way cool for other reasons as well[1-2]. Has anyone heard of an effort to do something like that?[3] [1] As some of you may notice, Quake 2 demands that it run in a directory with _all_ of its data files -- some of which normal users may change (eg, baseq2/config.cfg), and some of which normal users will probably never change, but might (eg, baseq2/pak?.pak). As it's done now, symlinks are created to files users are unlikely to change, and files users are likely to change are copied. With copy-on- write links, all files would be copy-on-write links, and the user can change any file, without wasting any more disk space than actually necessary. [2] The files in /etc/skel that get copied to new users' home directories might be changed by root from time to time, for whatever reason. Not all users are knowledgeable enough to change them, and of those who are, only some understand that they need to remove a symlink and copy the source file and edit that. With copy-on-write links, `adduser' would simply create copy-on-write links to the files in /etc/skel in a new user's home directory, and that new user can play with those files if they wish, and if they don't, they'll automatically receive updated versions of those files whenever root changes them in /etc/skel. [3] I understand Microsoft has done something like that in one of their operating systems or another. It was on Slashdot a while back. Most people said that what they `invented' are really just symlinks, but the major difference is that they're copy-on- write, whereas writing to a symlink on Unix will write to the file pointed to, but overwriting a symlink will overwrite the symlink, not the file pointed to; this is a pseudo-copy-on-write behavior, but not real copy-on-write like what MS did. Of course, they attached some lame marketroid buzzword TLA to it, but `copy-on-write link' works for me. ;) Regards, Alex.
