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
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.
Reply to: