Re: setuid/setgid binaries contained in the Debian repository.
Hi,
On Mon, Aug 11, 2003 at 05:48:19PM -0400, Matt Zimmerman wrote:
> On Mon, Aug 11, 2003 at 10:36:35PM +0200, Emile van Bergen wrote:
>
> > On Mon, Aug 11, 2003 at 04:16:24PM -0400, Matt Zimmerman wrote:
> >
> > > It would be nice indeed; it also turns out to be horrifically complex
> > > when you consider dependency relationships, unless you force the user to
> > > install another copy of all system software in their home dir as well.
> >
> > Well, dpkg should probably concatenate /var/lib/dpkg/status and
> > ~/var/lib/dpkg/status internally to see if build dependencies are already
> > satisfied by the global system.
> >
> > Most --configure scripts should be able to search ~/lib as well as /lib,
> > /usr/lib and /usr/local/lib.
> >
> > I don't see how this would be prohibitively complex. Sure, there are some
> > issues to be worked out, but basically comes down to allowing each user to
> > add a user-specific part to the in-memory package database when running
> > the package management tools.
>
> Don't you think you are oversimplifying a bit?
I am, but I think 'horrifically complex' isn't entirely accurate either.
> You have glossed over a lot of very significant concerns:
>
> - properly resolving dependencies in this scenario is a lot more complex
> than concatenating two status files together. Consider Conflicts, for
> instance. Then Replaces. Then Provides.
Sure, you have to remember which entry comes from the system part and
which from the user part.
Conflicts: checks the whole database. If it matches a system entry, the
package cannot be installed. If it matches a user entry, you get standard
Conflicts handling.
Ditto for Replaces; the user cannot replace files owned by system
packages, as simple as that.
I don't see immediately how Provides needs special handling, but I'm no
expert.
> - nearly every single package would need to be modified (the source code,
> not the packaging) to support relocation
True. On a one-by one basis. A user would be happy with some installable
packages. A lot of KDE/GNOME app(lets) and utilities all have similar
packaging or even come from one source package.
> - if by "--configure" you mean autoconf-generated configure scripts, most
> packages don't even use autoconf, and even if they did, autoconf doesn't
> search the way that you have described, and neither does ld.
I'm sure autoconf allows --prefix to be set to /home/$USER and I don't
doubt that autoconf can cause -L$prefix/lib to be added to LDFLAGS.
Without autoconf, adding support in the package's build system for "make
prefix=/home/$USER" should be a good starting point. Maintainers already
have to hack most build systems to implement $installdir. Adding $prefix
is hardly a burden if you had implement $installdir for your package.
I'm also willing to bet that more upstreams already have support for
$prefix than $installdir.
Not solving it is also fine, I'm just pointing out it isn't so hard as
you make it look like. It still seems the best solution to me, but I'm
open to suggestions.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)70 3906153 http://www.e-advies.nl
Reply to: