[aur-general] Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

[Eli Schwartz]

On 4/16/19 9:19 AM, Lone_Wolf wrote:
> Hi,
> 
> 
> recently a mesa developer contacted me and asked me to change mesa-git
> to depend on released llvm/clang instead of llvm/clang trunk.
> 
> He did convince me there's a demand for such a package.
> 
> 
> Currently people wanting to build mesa-git against released versions
> need to edit the pkgbuild and make a few changes (not documented atm).
> 
> I have been building mesa trunk against llvm trunk since mesa started
> using llvm and tailored the package to my personal workflow and style.
> 
> Adjusting the mesa-git PKGBUILD to use repo llvm/clang would force me to
> either change my workflow or maintain a package I don't use in that form.
> 
> I'd probably stop maintaining mesa-git.
> 
> 
> I do feel there's an underlying issue here that concerns us all as
> stated in the title:
> 
> Are AUR VCS packages that depend on AUR VCS packages from other projects
> a good idea and who should decide on that?

The AUR package maintainer is trusted to use his or her discretion when
selecting which version of llvm to target. It's assumed that the AUR
maintainer is competent enough to know the benefits and costs of
choosing one or the other.

If people have issues with the AUR maintainer's choices, they may
provide suggestions or ask for explanations, but at the end of the day,
the AUR maintainer can just say "I have X and Y reasons for doing it
this way, and I don't believe doing otherwise would be serving the
community".

Since you seem to have a pretty good rationale for why users using
mesa-git would *per default* wish to use llvm-svn, I see no reason to
change anything.

Anyone else who wants, is free to upload a new AUR package called e.g.
mesa-half-git -- not sure what to call it exactly, but you make
convincing arguments that it isn't the default expectation and isn't
exactly what one would expect the natural mesa-git experience to be.

It seems reasonable to leave things as they are, and perhaps prioritize
adding comments to document what changes are needed. You could even add
a variable at the top of the PKGBUILD, _USE_STABLE_LLVM= with a comment
that setting the variable to non-empty will automatically make those
changes.

-- 
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/20190416/e5f1c0cf/attachment-0001.sig>