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

[Bruno Pagani]

Le 03/05/2019 à 17:14, Eli Schwartz via aur-general a écrit :
> On 5/3/19 10:23 AM, Bruno Pagani wrote:
>> Le 03/05/2019 à 16:04, Eli Schwartz via aur-general a écrit :
>>> Lone Wolf's point here, is that mesa-git results in different codegen
>>> and different features, if the build-time compilation environment is
>>> llvm-git.
>> Yes, so say so in a pinned comment and be done with it.
>>
>>> It's not unreasonable to want the resulting package to have technically
>>> correct dependency linkages when its compilation environment results in
>>> *different dependencies*.
>> It’s user choice to use llvm-git instead of llvm. They are free to edit
>> the PKGBUILD to get correct dependencies listed on their system if they
>> want. But they are tons of software where building against the dev
>> version of a dependency binds you to it (or requires a recompilation to
>> switch back to the non-dev version). Just think of any software where
>> the soname bumped between release and current trunk for instance. Would
>> you advocate a specific PKGBUILD for all possible cases?
> In the case of a soname bump, the package doesn't care what you built it
> with, except indirectly. What it actually cares about is that you don't
> suffer ABI breakage -- the package functionality itself is, usually, the
> same.
>
> And soname bumps are really easy to spot, because ld.so has a builtin
> way of alerting you -- the lib won't even load. pacman also has the
> ability to be even more direct, if you depends=('libfoo.so').
>
> According to Lone Wolf, this is *not* just ABI breakage, it is, rather,
> feature autodetection.

Soname bumps were only one example of case where it binds you to the new
version. HDF5 stupidity in checking the patch version at runtime could
be another. And they have been other cases of feature detection, for
instance Knot DNS server was enabling Ed25519 if it detected support in
GnuTLS, which only happened with the dev version of GnuTLS for a very
long time. Should I have uploaded a package specifically depending on
the dev version of GnuTLS?

>>> Furthermore, if one would host the resulting package in a prebuilt
>>> binary repository, I defy the idea that users failing to realize they
>>> need llvm-git specifically, is "user stupidity".
>> Although this one is a good point, I would then say that the person
>> handling the binary repository should switch the dependency to llvm-git
>> before building. If they go the way of publishing a package, they can
>> afford a `sed` in their publication toolchain. And they should also
>> provide a matching binary llvm-git, because I expect the dep to be the
>> exact same as the makedep in this case, since a newer llvm-git than
>> build-time one could break things, just like llvm-git does w.r.t. llvm
>> from the repos.
>>
>>> Furthermore, I defy the idea that even users building it themselves
>>> constitute "user stupidity", because as Lone Wolf's explanation
>>> *explicitly* called out, it is awkward in the extreme to kludge around
>>> adding a *build-time* codegen dependency on llvm-git, inside a
>>> makechrootpkg compilation environment... without actually doing so via
>>> makepkg's "makedepends" technology.
>> I did not understood that paragraph.
> Lone Wolf already explained it, but I will explain it again.
>
> extra-x86_64-build, or custom derivations like myrepo-x86_64-build (with
> matching /usr/share/devtools/pacman-myrepo.conf) will pull in the
> default provider of a makedepends, which, if that is llvm, will result
> in llvm being installed, *not* llvm-git. This is okay if you just want
> to build against "the llvm project", and as long as the soname matches,
> no big deal. It is not okay, if you specifically want to build against
> specific revisions of llvm-git. One workaround is to not rely on
> makechrootpkg's ability to build with makepkg -s, but instead pass the
> following options on every single invocation:
>
> -- -I /path/to/llvm-git.pkg.tar.xz -I /path/to/llvm-libs-git.pkg.tar.xz
>
> Considering that makepkg already has a builtin way to handle specifying
> make/dependencies, and the package maintainer has specifically described
> llvm-git, as opposed to llvm, as a feature autodetection dependency, it
> seems reasonable to me to specify the feature dependency explicitly.

This seems a moot point to me. Either you are not using a custom repo,
and pacman won’t be able to resolves -git packages anyway, so you have
to specify them manually like you did; or you are using a custom repo,
in which case you should set things up so that llvm-git from it is taken
over llvm from [extra] (using e.g. `replaces` or giving the repository
an higher priority).

> Most -git packages, conversely, can be compiled against the release
> version of a dependency and run against the -git version of the
> dependency, without generating a different package that may or may not
> work and probably behaves differently.
>
> ...
>
> Now, getting back to the original question which Lone Wolf posed, what
> should be done here, when the package maintainer is considering the
> following concept:
>
> "Exercising my discretion as the package maintainer, I believe people
> who install mesa-git want to use all the latest mesa-git features. It
> does happen to be that the latest mesa-git features depend on llvm-git."
>
> I'm highly sympathetic to this desire, as it seems quite reasonable to me.

Yes, and he can solves that by *pinning a comment telling so*. ;)

Regards,
Bruno