On 2/7/19 8:00 PM, james harvey via arch-projects wrote:

I guess I'm abusing devtools a bit, as a few others are. I use devtools to build modified official packages when necessary, and to build AUR packages even if they depend on other AUR packages. I add a local repository to "/usr/share/devtools/pacman-extra.conf", and to /etc/pacman.conf as a CacheDir so it is bind mounted. I also add to "COMPRESSXZ" "--threads=0" to "/usr/share/devtools/makepkg-x86_64.conf".

Maybe others using devtools similarly are using a customized version of archbuild using its own pacman and makepkg conf files, which is what I used to do. I stopped so when devtools updates its conf files, it would overwrite my changes and I'd just add them back in. Otherwise, I might miss merging changes into mine.

You can override pacman.conf much more simply. sudo cp /usr/share/devtools/pacman-{extra,myrepo}.conf sudoedit /usr/share/devtools/pacman-myrepo.conf sudo ln -s archbuild /usr/bin/myrepo-x86_64-build Then build packages using `myrepo-x86_64-build`, and instead of building against the "extra" target, you will be building against the "myrepo" target. Changing makepkg.conf is usually somewhat questionable. What's the goal -- changing COMPRESSXZ seems rather wasteful since you could just set PKGEXT='.pkg.tar' and not compress at all, if you're worried about how long it takes.

Or, maybe they run mkarchroot/arch-nspawn/makechrootpkg directly.

Using makechrootpkg sounds like an excellent idea. The purpose of archbuild is to provide presets for makechrootpkg and to run mkarchroot automatically for you on demand, but you explicitly don't want those presets, so... why? Why use it? The only thing that keeps on rewriting your makepkg.conf inside the chroot, is archbuild. Just create a bashrc: alias chrootbuild="makechrootpkg -r /var/lib/archbuild/myrepo-x86_64" and you're reimplemented the most significant part of every devtools wrapper ever.

Or, maybe they use graysky2's clean-chroot-manager, which I haven't looked at yet.

Basically the alias except it also tries to do complex magic with distcc.

It still seems odd to me for "/usr/share/devtools/*.conf" to show variables that are never read from it, and personally would replace those with a comment referring to /etc/makepkg.conf, but I respect if the answer is that I shouldn't have been confused because I shouldn't have been looking at them in the first place.

It's perfectly possible to "arch-nspawn -M /etc/makepkg.conf" and install your regular makepkg.conf into the chroot, and if that happens then you also have things being ignored. /etc/makepkg.conf will be *overridden* by $HOME/.config/pacman/makepkg.conf, and makechrootpkg will likewise be *overridden* by these variables. I don't see the benefit of creating differences between the devtools/makepkg.conf and the one that comes as stock in pacman, just for this. -- Eli Schwartz Bug Wrangler and Trusted User

On Thu, Feb 7, 2019 at 12:15 PM Eli Schwartz via arch-projects <arch-projects@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.