[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 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.

>> 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.

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.

-- 
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/20190503/5e6eb58a/attachment.sig>