[aur-general] PKGBUILD with side-effects outside of build-dir

[Eli Schwartz]

On 9/5/20 7:30 PM, Knut Ahlers wrote:
> Hey there,
> 
> Today I received a comment [1] on one of the packages I'm maintaining
> asking for a change which I'm really not sure about:
> 
> Basically the requested change is to have the build use an external
> environment variable (if set) which allows the packager to use an
> directory outside of the current build directory (the directory
> `makepkg` was executed in) for build assets.
> 
> This would on the one hand allow packagers to reuse crates already
> built and not to build every dependency again within the build process
> of the package itself.

The correct way to do something like this within one package is the way
it is done for ccache, i.e. a mechanism by which the compiler can check
to see if the current command line would result in identical output to
some previously cached compiler output, and simply reuse that.
C/C++-based projects can frequently benefit from this during rebuilds.

The correct way to do this for content originally built by some totally
unrelated package is not at all. This is what depends=() is for, and
static/shared libraries. It's not a makepkg problem if
rust-the-programming-language is *deliberately* slow as molasses.

(There is no reason why something like ccache should not *still* work in
this case, even though it's ill language design compared to
system-installable rlibs. However, the point remains that there should
be dedicated interfaces to this such as how ccache currently works via
makepkg.conf, not "set this random environment variable before running
makepkg to cause it to sidestep using $srcdir".)

> On the other hand this would introduce
> side-effects to the package building process and also the system of
> the packager. For builds within isolated environments like Docker
> containers this would basically not change anything.
> 
> My personal opinion is strongly biased against allowing side effects
> outside of the build-dir itself and against letting
> (developer-)environment-settings, of the systems which execute the
> build, interfere with the package build. In my opinion the build
> should stay in a way neither is allowed or at least prevented as far
> as possible.

I agree with you that this should not be done. Again: setting random
environment variables before running makepkg is not and should not be
supported in any way for changing how makepkg works or tearing $srcdir
out from under it.

Furthermore, the side effects seem to be worse than just ugliness: I
googled "CARGO_TARGET_DIR shared" and the top two results (other than
the manual page for CARGO_TARGET_DIR which is a false positive; it
didn't mention sharing them) were unfixed bug reports. e.g.

https://github.com/rust-lang/cargo/issues/7740

In fact, every single result on the first page, if it had anything to do
with the search query, at least warned that you might not want to this
since it works on some projects and breaks others due to rust not
knowing the difference between different crates or binaries with the
same name. Half of them mentioned sccache (ccache alternative) as the
superior option. sccache marks its rust support as experimental, but
that seems to mean it doesn't always successfully cache results, not
that it returns the wrong information.

> As I did not find advice / consent on this in the Wiki or AUR-General
> I'd like to have some opinions of other package maintainers on this:
> How would you like to have package builds behave?
> 
> Act as isolated as possible, not reacting to outside influences (like
> env-vars) though this will never be fully achieved without some
> wrapper wiping all env-vars from the outside…
> 
> OR
> 
> Allow interference of outside influences and allow modifications
> outside the build directory (for example store the build artefacts
> outside the build-dir and package them from there)…
> 
> Cheers,
>   Knut
> 
> [1] https://aur.archlinux.org/packages/dust/#comment-764039
> 


-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20200905/20d824bf/attachment.sig>