[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Installing debs in ~user/ or /usr/local?

On Sat, 5 May 2001 16:48:05 -0400
Matt Zimmerman <mdz@debian.org> 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
> > 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
> > are a good addition to tar.gz for distribution... but one argument he
> > was the question if non-root users could install debian packages?
> > 
> > Is this possible?
> Debian packages require root privileges for installation.  While you
> unpack a .deb in your home directory and use the files in it, you would
> 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,
> 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
users can install packages as they please, but fakeroot doesn't support
(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'
and while it for all intents and purposes seems to be running on bare
it really is a virtual machine. That would be quite fantastic for doing
privileged operations without a security risk, though.

This could also be useful for Debian developers. This way, they could not
develop their packages on Debian machines (on which they don't have root),
also test them. I imagine quite a few packaging bugs in unstable would be
out that way. ;)

For that to work, you'd also need to set up a base system for each and
developer. That would waste a lot of disk space in a hurry. Perhaps
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,
means big changes in the kernel's VFS code and possibly elsewhere, but
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,
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
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
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
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. ;)



Reply to: