public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Simon <turner25@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Binary package cruncher?
Date: Sun, 16 Nov 2008 09:59:57 -0500	[thread overview]
Message-ID: <4920356D.3040300@gmail.com> (raw)
In-Reply-To: <200811161205.53841.alan.mckinnon@gmail.com>

> I would build all that stuff in a chroot. The logic is that the your buildhost 
> system is not quite the same thing as the machine hosting the buildhost.

That's the big trick I was thinking about...

1) Make a proper development environment under a chroot, place the "binworld" on 
top of world.
2) emerge -k -uDN world
    (this will install, in the chroot env all dependencies using previously 
built binpkgs, if those dependencies don't exist, they will be built and binpkg 
will be made for everything that is built)
3) un-chroot properly (unbind directories, etc)
4) delete the chroot directory containing installed dependencies, not relevant 
to the production environment

This would build the packages and install nothing on the host.  But I'm not sure 
if chroot is really proper for this... maybe I would have to use a unionfs to 
make sure that nothing gets overwritten in /lib or gets installed in the real 
/lib for example...

After everything is built, i would just redo the `emerge -k -uDN world` on the 
host in the real production environment to update it.

> One thing you cannot get away from is that to build say X for your slow 
> hardware, it has to be done on a machine that has all X's build dependencies 
> fully installed and working. You might not want that on your production 
> server. Some fancy tricks with bind-mounts into the chroot would let you 
> share common stuff. Or, you could simply buy a bit more storage if you are 
> running out. It's cheap enough and if you've gone to this much trouble 
> already, some more storage would be minor

You're right and this is why I had installed X on my host, with all its deps, 
even though none of it was used.  But using the chroot (and/or unionfs trick) 
I'd be able to build it with its deps without really installing it on the prod 
environment.

However, diskspace on a VPS is very costly.  For example, one extra GB is 
2$/m... and with the cheapest VPS i have only 12GB now.  I'm sure my full 
production environment would not move much higher than 4GB (without counting 
/usr/portage) while it probably is filling my disk now...

So, basically, if gentoo is a meta-distribution, my host is "my" distribution 
and serves to build the packages that are then available to my PCs...

Thanks,
   Simon



      parent reply	other threads:[~2008-11-16 19:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-15 17:40 [gentoo-user] Binary package cruncher? Simon
2008-11-16 10:05 ` Alan McKinnon
2008-11-16 11:16   ` Peter Humphrey
2008-11-16 15:03     ` Simon
2008-11-16 14:59   ` Simon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4920356D.3040300@gmail.com \
    --to=turner25@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox