[Dev] Fauno's workflow

[Luke T. Shumaker]

At Fri, 30 Nov 2012 15:29:56 -0300,
Nicolás Reynolds wrote:
> "Luke T. Shumaker" <lukeshu at sbcglobal.net> writes:
> > It copies the packages in ${chrootdir}/srcdest to your configured
> > SRCDEST outside of the chroot; where normal `makepkg` would put them.
> 
> but srcdest is for downloading sources... why copying if you can have
> them all in the same place anyway? :D

Because the file ownership of the outside srcdest (you) and the inside
srcdest ("nobody") are different.

> > > it may also bind mount a subdir on home where you store abslibre and
> > > libretools (i use the git version) and that's clean enough. it's never
> > > been a problem though.
> >
> > Eh, I'm a fan of getting an up-to-date libretools on the repos.
> 
> it's not enough if i'm testing changes to libretools itself ;)

Well then, that's what /repo is for, put the testing package there.

> > > >  * A chroot also protects you from a misbehaving build script messing
> > > >    with your $HOME.
> > > 
> > > i usually check pkgbuilds from aur and trust the ones that come from
> > > abslibre...
> >
> > Not just the PKGBUILDS, but the Makefiles, ant scripts, etc that are
> > part of the source.
> 
> ok then refer to mount chroot's ~ to something that contains libretools
> and abslibre (or just abslibre):
> 
> $ ls ~/packages/
> abslibre/
> packages/
> sources/
> 
> $ mount --bind ~/packages $chrootdir/home/$USER/

I'll consider this. Perhaps I'll make bind mounts configurable, so you
can configure whatever mounts you want.

> >> chcleanup is run automatically here, not optionally. -c is needed when
> >> the chroot is considered dirty if not pristine so it may remove the
> >> packages you already installed if this is the second run, and this isn't
> >> the case: chroot is considered dirty when more than the needed packages
> >> are installed.
> >
> > How is it done automatically?
> 
> it's always run by treepkg before makepkg, no flag involved, and it's a
> tiny script that just knows what to remove instead of removing
> everything just in case (rsync is slow and btrfs is overkill in
> comparison to a *tiny* script that runs pacman -Rn
> packages-not-in-base-or-pkgbuild).

How the tools clean has changed.

 librechroot -c cleans the chroot using chcleanup
 librechroot -s syncs it to a pristine chroot with rsync/btrfs 

I've also just (since I started writing the email) tought libremakepkg
to also run chcleanup for every build, since it isn't overkill like
the old package cleanup was.

> >> recreating here means "mounting and umounting, removing files, spawning
> >> shells...", why has this to be done many times when i can do it once or
> >> less? (yeeloongs aren't the quickest machines).
> >
> > I wish I hade a yeeloong to verify...
> 
> :c
> 
> but still, doing things many times unnecesarily doesn't sound kiss to
> me, as in i didn't had to rewrite libremakepkg, i just stopped using it
> ;)

My goal with rewriting libremakepkg was to "wrap makepkg, adding hooks
to do things for me that I'm doing manually now".

> > It's pretty minimal now.  The most complicated parts are:
> >  * handling signals to umount and exit gracefully
> 
> that's the problem with making it mount everytime instead of using
> fstab, you can end up with the same dir bind mounted many many times.

I think I fixed that bug. Before it trapped the signals so that when
there was an error, it went to the umount function. The first thing
that function did was reset the traps to the exit function. This was
bad because it meant that it might exit early and not umount
everything.

I think that modifying the outside fstab is too invasive into the
user's system.

> >  * the legacy code that only runs if systemd-nspawn isn't available
> 
> this should be deprecated imo

I agree, but removing it would involve patching devtools even more
than I already do.  I'm trying to keep it so that I can still pull
changes from devtools.

> > And some of the "checks" can only be done with a chroot, such as
> > turning networking off during the build and package stages.
> 
> this is true, but what we're discussing (except from the "running any
> command instead of a predefined set" part) does still apply.

I'm not sure what you mean. In order to toggle the networking you must
exit and re-enter the chroot.

Happy hacking,
~ Luke Shumaker