[arch-dev-public] Punishment needed for not building in a chroot

Eric Bélanger snowmaniscool at gmail.com
Sun Dec 6 21:20:38 EST 2009

On Sun, Dec 6, 2009 at 8:58 PM, Allan McRae <allan at archlinux.org> wrote:
> Paul Mattal wrote:
>> Giovanni Scafora wrote:
>>> 2009/12/6, Allan McRae <allan at archlinux.org>:
>>>>  It is as simple as mkarchroot to make the chroot and makechrootpkg to
>>>> build
>>>> the package (providing the path to the chroot as an arguement).
>>>>  Making a chroot for the opposite architecture is slightly more
>>>> difficult,
>>>> but I can provide patches if needed.
>>> mkarchroot to make the chroot and makechrootpkg to build is very sample.
>>> I think that patches are not necessary...
>> I agree that it's pretty simple, but not simple enough to have removed the
>> barrier to everyone doing it. So why not make it easier and get rid of more
>> of the mystery?
>> Let's start at the beginning, with the recommended command for creating
>> chroots:
>> sudo mkarchroot -C <pacman.conf> -M <makepkg.conf> <chrootdir>/root base
>> base-devel sudo
>> For starters, I have to trust mkarchroot pretty well not to have any bugs,
>> because I'm sudoing it.
> I'll never understand why people are more scared about their root filesystem
> being damaged when you can easily recover that using pacman.  All our
> db-scripts could destroy your /home/<user> data which is much more difficult
> to recover from backups but I bet you never second guess them.
>> Then I need to find the pacman.conf and  makepkg.conf.
> That is optional.  But most people want to keep their makepkg.conf for the
> PACKAGER variable and MAKEFLAGS.
>> Then there's the chrootdir/root--- now do I create that first or not? How
>> much of it?
> No idea...  my guess is that "mkdir -p" is used, but I have always created
> <chrootdir>/
>> Who's going to own the stuff in there?
> It is a system chroot, so files are owned by whoever owns the corresponding
> files in the packages your are installing.
>> What stuff will it put in there? Where will it keep the differencing data
>> for the unionfs partition (so I can be sure to have enough disk around)?
> Everything is in <chrootdir>.  <chrootdir>/rw for the difference data and
> the union is created in <chrootdir>/union
>> Then I should decide-- if I have i686 and x86_64 boxes, is it better to do
>> all my builds on 1 machine, or on separate boxes? Can I build i686 on
>> x86_64? Can I build x86_64 on i686? If I'm going to set all this up, I'm
>> probably going to set it up on several machines-- how can I do that easily?
> Up to you...   I build for x86_64 and i686 on my i686 comp (running x86_64
> kernel).  I know many people build for i686 on x86_64.  I used to have a
> separate build machine for x86_64.  All combinations can work.
>> I'm not saying people can't/won't/shouldn't do this. I'm saying it's not a
>> particularly kept-simple part of a distro that prides itself on keeping
>> things simple. People will do it if they trust it and it's simple and
>> elegant, just like the rest of Arch.
> In all honesty, I rarely ever create a new chroot but that is definitely the
> most difficult part of the lot. You should only need to create a chroot
> once.  My workflow goes:
> update chroot:
> sudo mkarchroot -u /home/stable-i686/root/
> build package:
> sudo makechrootpkg -c -r /home/stable-i686/
> Done.  Alias them to "mar" and "mcp" and possibly add them to the NOPASSWD
> section of your sudoers file and the process will become even simpler...
> For soname bumps it is slightly more complicated.
> build package with library bump and install in rw layer:
> sudo makechrootpkg -c -r /home/stable-i686/ -- -i
> then, build next package against new library from installed package:
> sudo makechrootpkg -r /home/stable-i686/
> The creation of the chroot could be simpler, but I'm not sure we can make
> the building steps much simpler without removing the flexibility of the
> tools.
> Allan

I have an helper script to manage my many chroots (testing,
non-testing, i686, x86_64). It's somewhat trivial but I could post it
if someone's interested.

More information about the arch-dev-public mailing list