[arch-projects] [devtools] uses MAKEFLAGS (+others) from /etc/makepkg.conf not /usr/share/devtools/

[james harvey]

On Thu, Feb 7, 2019 at 12:15 PM Eli Schwartz via arch-projects
<arch-projects at archlinux.org> wrote:
> On 2/7/19 6:14 AM, james harvey via arch-projects wrote:
> > I got extremely confused when I accidentally found out that the
> > MAKEFLAGS that is needed to be set for parallel building using
> > devtools is the one in "/etc/makepkg.conf", instead of one like
> > "/usr/share/devtools/makepkg-x86_64.conf".
> >
> > Turns out this is because "makechrootpkg"::20180531-4::638 is:
> >
> >    load_vars /etc/makepkg.conf
> >
> > load_vars() only reads "{SRC,SRCPKG,PKG,LOG}DEST MAKEFLAGS PACKAGER",
> > so without me having set any of the others, it turns out the only
> > variable it uses from /etc is MAKEFLAGS.
> >
> > For me, I think this is the only makepkg/pacman variable in an entire
> > devtools run that isn't out of /usr/share/devtools, since "archbuild"
> > gives those to "mkarchroot" and "arch-nspawn... pacman -Syu", and they
> > are copied into "/var/lib/archbuild/extra-x86_64/root/etc/" for
> > anything ran in the chroot.
> >
> > Should this be fixed?
>
> No, the purpose of makechrootpkg is to isolate builds. The explicit
> intent is that makechrootpkg *MUST NOT* respect makepkg.conf from the
> host in order to change the output of a package. CFLAGS change the
> output of a package -- imagine how completely horrible it would be if
> one used CFLAGS="-march=native" on the host machine, and that leaked
> into the clean chroot build and got published to a public repository.

I should have been more clear.  By "this be fixed", I didn't mean for
makechrootpkg to take more variables out of makepkg.conf.  I meant for
it to take no variables out of makepkg.conf, only makepkg-x86_64.conf.
But, I get the value now in having /usr/share/devtools/* never be
modified so no mistakes happen, and just take the variables out of
/etc/makepkg.conf that it already takes.

> makechrootpkg uses makepkg.conf just like makepkg does. The content of
> the copydir is meant to be completely opaque -- you're not supposed to
> think about it or acknowledge it exists, unless you're attempting to
> develop on the script itself.
> The difference between makepkg and makechrootpkg is that the latter only
> respects:
> - the *DEST options, which simply control what is bind-mounted into the
>   chroot,
> - MAKEFLAGS, which does not change the output of a package, and
> - PACKAGER which is part of the pacman -Qi metadata and by definition
>   needs to be set per packager.
>
> Please note the help output for makechrootpkg:
>
> ```
> $ makechrootpkg -h
> [...]
> This script reads {SRC,SRCPKG,PKG,LOG}DEST, MAKEFLAGS and PACKAGER
> from makepkg.conf(5), if those variables are not part of the
> environment.
> [...]
> ```

Got it, thanks.

> > I originally thought of a new "makechrootpkg
> > -M" option, but I think it could instead run:
> >
> >    load_vars ${copydir}/etc/makepkg.conf
> >
> > If not, should "/usr/share/devtools/makepkg-x86_64.conf" be updated
> > with a comment where those variables are, to say they're actually used
> > out of "/etc/makepkg.conf"?
>
> Now this confuses me -- what do you need to load vars from the copydir
> for? makepkg reads this on its own, makechrootpkg is just meant to copy
> select variables *into* the ${copydir}/etc/makepkg.conf

Argh.  You're right.  I hadn't followed what "makechrootpkg" did with
the variables after loading them.