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