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

Relocation of Debian packages into home directories and such (Re: setuid/setgid binaries contained in the Debian repository.)



On Tue, Aug 12, 2003 at 01:29:32AM +0200, Emile van Bergen wrote:

> On Mon, Aug 11, 2003 at 05:48:19PM -0400, Matt Zimmerman wrote:
> > Don't you think you are oversimplifying a bit?
> 
> I am, but I think 'horrifically complex' isn't entirely accurate either.

I disagree.  This would be very difficult to get right.

> > 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.

You have to reconsider fundamental assumptions in nearly every package in
the archive.  Debian packages contain a number of scripts that we call
"maintainer scripts", such as prerm, postrm, preinst and postinst, and
these, by and large, assume that they are running as root, that they will
base their actions on the real root of the filesystem, and that when they
invoke other programs, they too will act on the same root.

> 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. 

Packages conflict for reasons other than file overlap.

> Ditto for Replaces; the user cannot replace files owned by system
> packages, as simple as that. 

No, it is not, in fact, as simple as that.  Perhaps you should read section
7.5 of the policy manual, which describes how Replaces works.

> I don't see immediately how Provides needs special handling, but I'm no
> expert.

Do you base your analysis on experience building and maintaining Debian
packages?  On the documentation for the packaging system?  Or on something
else?

> > - 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.

Of course autoconf uses --prefix; I never questioned that.  However,
supporting LDFLAGS correctly is entirely up to the build system, and if
you'd ever tried it, you'd find that it (like CFLAGS) often doesn't work, or
doesn't work the way you expect.

I'm not interested in debating this subject any further; if you think that
this would not be prohibitively difficult, then I suggest that you implement
it, because it would be a useful feature.

-- 
 - mdz



Reply to: