Re: using makepkg.conf to set arbitrary environments (was: aur/solr: Unknown PGP key)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 07/30/2018 12:23 PM, Ralph Corderoy wrote:
> I'll be more clear.
> 
>     makepkg(1) says `makepkg is a script'.
>     It doesn't say what kind of script, e.g. sh(1), bash(1), ...
> 
>     makepkg.conf(5) says `This file is sourced',
>     but again doesn't state the language.

Well, on the other hand the actual makepkg.conf contains a *bash*
shebang. :)

Anyway my default rule when a file is "sourced" is to stick with the
lowest common denominator, that is to say, POSIX sh, since it would
therefore work regardless.

However, in this case makepkg.conf lists a number of options that are
part of makepkg.conf's formal API, which are represented by shell
arrays, which indicates that POSIX sh is insufficient and you need bash.
One who notices this could easily infer without leaving the
configuration file, that it is bash.

I'll ignore zsh on the grounds that no one *actually* writes programs in
zsh...

...

So, two points that definitively confirm it is bash, and a
guaranteed-safe fallback in sh for people who don't notice this.

> Right, that add up to thirty-odd variables.  I wasn't arguing that
> `GNUPGHOME' should be magically exported just be being assigned in
> makepkg.conf, but stating it won't be exported because, quite
> reasonably, it isn't in makepkg.conf(5)'s list.  Thus some method of
> exporting it would be required.
> 
> But makepkg.conf(5) just shows variable assignments because it's
> explicit they'll all be exported so the export syntax for this unknown
> language isn't shown.

It is, technically, a lie that they'll be exported, since many are not
but it doesn't specify what it actually means there and basically
implies that everything on that page is in fact exported to all
subprocesses.

Although I'm not sure if this generally matters as the ones used for
internal state won't surprise people when some Makefile does not honor
them, and moreover, half of them are arrays which aren't variables and
cannot be exported as environment *variables*.

> Besides, it's a lot more clear to have makepkg.conf(5) say it's bash(1)
> syntax and any bash code is acceptable, than see it's a list of
> `VAR=value' and wonder if deviating from that would be fragile and break
> in the future even if it's OK today.  mkinitcpio.conf(5) has the same
> issue.

Patches welcome! Developers often do not realize that what seems obvious
to us (cf. my above inferences regarding the language syntax) are
non-obvious to others. When confusion arises, this is a good opportunity
to get outside perspective on the matter (and, coincidentally, a sneaky
way to trick people into becoming contributors :D).

-- 
Eli Schwartz
Bug Wrangler and Trusted User

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux