%% Paul de Vrieze <pauldv@g.o> writes:

  pdv> On Wednesday 24 March 2004 15:44, Paul Smith wrote:

  >> This isn't what I'm looking for, actually.  I want to be able to
  >> build an install area with complete freedom from my "real" desktop.
  >> I want to build with completely different versions of all sorts of
  >> tools than the ones on my "real" system, without having to install
  >> them on my real system.

  pdv> This is exactly what chroot does.

No, chroot does more than this.  Chroot also (a) requires root
privileges which I don't want to require, and (b) makes my real system
unavailable to me.  Right now we avoid a lot of the overhead of the
"build" image by using "emerge inject" and relying on the natively
installed tools like wget, python, perl, shell, native compiler, etc. etc.

  pdv> There is not really a way to avoid it either as there are many
  pdv> packages which rely on certain locations for certain files. In
  pdv> many cases it is possible to say those files exist in $ROOT but
  pdv> then it would not work if that root would become the real root.

I'm not proposing that these alternate images should be _runnable_ as
they are.  I only want them to be _created_ that way.  Before they are
run they will be transferred to a target system and placed in "/".

  >> The other change I would like to see is a way to avoid the requirement
  >> for root access.  These extra "images" I'm creating don't need to be
  >> installed as root, because I'm creating them in my own area.  Not only
  >> that, but if there's a personal BUILDROOT then even _THAT_ doesn't
  >> require root access; it could also be an image I've built myself.

  pdv> We need root access for being able to give packages the right
  pdv> permissions. There might possibly be a way around it for creating
  pdv> binary packages, but that would probably require either some
  pdv> LD_PRELOAD magic (like sandbox) or custom kernel modules to
  pdv> record the owners of files.

During the transfer of our images into the target we take care of
the permission problems.  But, we need end-users to be able to run these
builds without requiring root privileges.

It _would_ be cool, though, if we could track the chown operations that
Portage would normally run, rather than actually doing them; say, in a
file in the EDB.  Then we could have a more generic way of setting the
right permissions during the transfer operation.

  pdv> What you might try is user mode linux. What I understand from it
  pdv> it is possible to run it as a normal user.

We are using UML to test our built images, but we don't want to use it
for building the image itself.  It's much slower for one thing, and our
builds are already quite long enough, thanks! :).

  pdv> Some files in the apache package are owned by the apache
  pdv> user. There are many other packages with non-default owned
  pdv> files. That is essential for the security, and it is not possible
  pdv> without big changes to those ebuilds to actually use them when
  pdv> install is not performed as root.

I understand these issues, but we have already solved them locally.
First, we only use a very strict subset of packages and the ones we use
do not, as a rule, have this problem.  Second, as I mentioned above we
manage the permissions change during the transfer of the image to the
target.

  pdv> Before you do, try to build a full system with what you have. I
  pdv> think you will meet many of the above problems.

We've been using our system to build complete setups since last
summer... in fact they are deployed and running on our targets right now.

I admit that it's possible our needs are too specialized for inclusion
in the generic Portage.  I'm willing to keep a locally modified version
if that ends up being the case.  However, all things being equal I'd
prefer to see standard Portage be flexible enough for what we want
(saves merge effort on our part--and who knows, some other folks might
find it useful as well).

So far I'm proposing two changes:

 1) Addition of BUILDROOT to replace "/" for the build system lookups.

 2) Ability to install without root privileges.


It seems like the first might be more easily adopted by Portage than the
second, which might require a little more fleshing out.

Any interest in patches for either or both of these?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@...>   HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

--
gentoo-dev@g.o mailing list