[Dev] Fauno's workflow

Nicolás Reynolds fauno at kiwwwi.com.ar
Fri Nov 30 17:28:44 GMT 2012


"Luke T. Shumaker" <lukeshu at sbcglobal.net> writes:

> Fauno put this file in /doc/ in libretools, but I felt the best way to
> discuss it was an email
>
> Fauno wrote:
>> ## fauno's way
>> 
>> During packaging, I don't usually restart a build from scratch if I have to
>> make changes to the PKGBUILD. I use a lot of commenting out commands already
>> ran, `makepkg -R`, etc. When I used `libremakepkg` I ended up using a lot more
>> `librechroot` and working from inside the unconfigured chroot, because
>> `makechrootpkg` (the underlying technology for `libremakepkg`) tries to be too
>> smart.
>
> I'm not sure that's a "safe" way to build packages. I might do that
> while getting a package to build, but I always build from scratch at
> the end. "ccache" makes this bearable.

i'm a daredevil B)

> Also, libremakepkg no longer uses makechrootpkg, and is *very*
> transparent and doesn't try to be too smart.
>
>  * Copies the PKGBUILD and sources in (ok, some clever things happen
>    to copy the sources)

which ones?

>  * Runs checks on the PKGBUILD (currently pkgbuild-check-nonfree,
>    eventually librenamcap)
>  * Runs "makepkg -o"
>  * Runs checks on the source directory

what kind of checks?

>  * Runs "makepkg -e" with networking dissabled in the chroot

sounds fine

>  * Copies the resulting packages to SRCDEST.

?


>> When I started writing `treepkg` I found that mounting what I need
>> directly on the chroot and working from inside it was much more
>> comfortable and simple than having a makepkg wrapper doing funny
>> stuff (for instance, mangling makepkg.conf and breaking everything.)
>
> There is still some mangling of pacman.conf that I don't understand
> (maybe it is important; I'm affraid to remove code I don't understand)
> https://labs.parabola.nu/issues/256
>
> However, all that happens to makepkg.conf is it sets PKGDEST and SRCDEST.

i remember it also rewrites the makepkg entirely everytime, so if you
use distcc (it requires setting DISTCC_HOSTS) it will disable it.

>> This is how the chroot is configured:
>> 
>> * Create the same user (with same uid) on the chroot that the one I
>> use regularly.
>> 
>> * Give it password-less sudo on the chroot.
>> 
>> * Bind mount /home to /chroot/home, where I have the abslibre-mips64el clone.
>
> I'm not sure that's a good idea; maybe it works for you, but
>  * A lot of tools look at configuration in $HOME; a chroot means it is
>    a fresh directory... unless you bind mount /home.

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.

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

>> * Bind mount /var/cache/pacman/pkg to /chroot/var/cache/pacman/pkg
>> * Put these on system's fstab so I don't have to do it everytime
>
> archroot (librechroot's backend) bind mounts that for you so you don't have to
> have it in fstab or do it manually.

but it's done several times, on fstab it's done once at boot.

>> * Configure makepkg.conf to PKGDEST=CacheDir and SRCDEST to something on my home.
>> 
>> Workflow:
>> 
>> * Enter the chroot with `systemd-nspawn -D/chroot` and `su - fauno`.
>> 
>> * From another shell (I use tmux) edit the abslibre or search for updates with
>>   `git log --no-merges --numstat`.
>> 
>> * Pick a package and run `treepkg` from its dir on the chroot, or retake
>>   a build with `treepkg /tmp/package-treepkg-xxxx`. (Refer to doc/treepkg
>>   here).
>> 
>> What this allows:
>> 
>> * Not having to worry about the state of the chroot. `chcleanup` removes and
>>   adds packages in a smart way so shared dependencies stay and others move
>>   along (think of installing and removing qt for a complete kde
>>   rebuild).
>
> `librechroot -c` now uses chcleanup to clean the chroot.

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.

>> * Building many packages in a row without recreating a chroot for every one of
>>   them.
>
> libremakepkg did not recreate the chroot automatically before, and
> can't now.

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

>> * Knowing that any change you made to the chroot stays as you want (no one
>>   touches your makepkg.conf)
>
> For someone who doesn't work from inside the chroot, only setting
> PKGDEST and SRCDEST seems to be a good balance between "don't mess
> with my stuff" and "just work".
>
>> * Hability to run regular commands, not through a chroot wrapper. I can `cd` to
>>   a dir and use `makepkg -whatever` on it and nothing breaks.

also rm packages from the build order (see treepkg), add or remove
packages from the repo, etc.

>> 
>> * No extra code spent on wrappers.
>
> Again, I'm working to make libremakepkg provide more checks than
> simply working in a clean chroot does.

checks are ok, i just feel chroot wrappers add complexity that's not
needed if you take the chroot as a working environment. less bugs to
trace down!

-- 
http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121130/d037a402/attachment.sig>


More information about the Dev mailing list