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?
Lone_Wolf
On Tue, 16 Apr 2019 15:19:37 +0200 Lone_Wolf lonewolf@xs4all.nl 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?
Lone_Wolf
Is there any reason it depends specifically on the -git package? Most of the time, you depend on the release package and those that use the -git version just build against that, no other changes needed.
Hi,
Le 16/04/2019 à 15:19, Lone_Wolf a écrit :
Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that?
Upstream generally. If packages are tightly coupled (e.g. ring-* as far as I’m concerned, or Intel GPU toolchain), they will likely depend on the VCS version of the other packages. If not, then they should depend on the normal version, and people are free to try substituting the VCS version for any of them on their own (just like they are substituting the initial package with the VCS one).
I don’t know enough mesa/llvm to tell how tightly coupled they are, but I guess that if upstream asks this, then likely not so much. I also don’t know how different the mesa-git PKGBUILD would be then, but you can still maintain a local branch with the differences for your usecase.
Regards, Bruno
On 16-04-2019 15:29, Doug Newgard via aur-general wrote:
Is there any reason it depends specifically on the -git package? Most of the time, you depend on the release package and those that use the -git version just build against that, no other changes needed.
On 16-04-2019 15:33, Bruno Pagani via aur-general wrote:
Hi,
Le 16/04/2019 à 15:19, Lone_Wolf a écrit :
Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that?
Upstream generally. If packages are tightly coupled (e.g. ring-* as far as I’m concerned, or Intel GPU toolchain), they will likely depend on the VCS version of the other packages. If not, then they should depend on the normal version, and people are free to try substituting the VCS version for any of them on their own (just like they are substituting the initial package with the VCS one).
I don’t know enough mesa/llvm to tell how tightly coupled they are, but I guess that if upstream asks this, then likely not so much. I also don’t know how different the mesa-git PKGBUILD would be then, but you can still maintain a local branch with the differences for your usecase.
Regards, Bruno
There are 2 types of problems.
1. runtime libraries
mesa-git built against a specific llvm version needs the runtime libraries of that version.
If those aren't present, user gets an error that doesn't mention llvm at all.
You can verify this by doing these steps :
- install mesa
- pacman -Rdd llvm-libs
- run glxinfo
glxinfo will show complaints like
libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri)
Nothing in the error messages points to the real cause : missing needed llvm run time libraries.
2. features/stability gotten don't match expectations
People that install mesa trunk usually want something that's not present or fails with [extra]/mesa.
In my experience many mesa trunk features/fixes require changes to llvm only present in trunk.
this tends to be the most visible when llvm trunk is hundreds or thousands commits ahead of releases.
A few years ago we had this situation :
mesa-git & llvm-svn were maintained by the same person.
mesa-git depended on llvm/llvm-libs.
I maintained mesa-radeon-git and built against llvm-svn / llvm-libs-svn.
Users of mesa-radeon-git (including myself) didn't have much problems.
Users of mesa-git that build against repo llvm had a lot more problems.
When that person stepped down as maintainer (fall of 2015) I took over mesa-git and Kerberizer took over llvm-svn.
Kerberizer agreed with my assessment that mesa-git should be built against llvm-svn , not llvm.
for almost 4 years mesa-git has been depending on llvm-svn with great success.
If I were to adjust mesa-git to built against extra/llvm, I would add a conflict with llvm trunk.
TL;DR : llvm trunk should be treated as a different version of llvm then the latest released version.
Disclaimer: The above is based on my years of experience as user, builder and maintainer of mesa-git.
If I am wrong, please show me proof.
Lone_Wolf
Le 16/04/2019 à 18:01, Lone_Wolf a écrit :
On 16-04-2019 15:29, Doug Newgard via aur-general wrote:
Is there any reason it depends specifically on the -git package? Most of the time, you depend on the release package and those that use the -git version just build against that, no other changes needed.
On 16-04-2019 15:33, Bruno Pagani via aur-general wrote:
Hi,
Le 16/04/2019 à 15:19, Lone_Wolf a écrit :
Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that?
Upstream generally. If packages are tightly coupled (e.g. ring-* as far as I’m concerned, or Intel GPU toolchain), they will likely depend on the VCS version of the other packages. If not, then they should depend on the normal version, and people are free to try substituting the VCS version for any of them on their own (just like they are substituting the initial package with the VCS one).
I don’t know enough mesa/llvm to tell how tightly coupled they are, but I guess that if upstream asks this, then likely not so much. I also don’t know how different the mesa-git PKGBUILD would be then, but you can still maintain a local branch with the differences for your usecase.
Regards, Bruno
There are 2 types of problems.
- runtime libraries
mesa-git built against a specific llvm version needs the runtime libraries of that version.
If those aren't present, user gets an error that doesn't mention llvm at all.
You can verify this by doing these steps :
install mesa
pacman -Rdd llvm-libs
run glxinfo
glxinfo will show complaints like
libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri)
Nothing in the error messages points to the real cause : missing needed llvm run time libraries.
- features/stability gotten don't match expectations
People that install mesa trunk usually want something that's not present or fails with [extra]/mesa.
In my experience many mesa trunk features/fixes require changes to llvm only present in trunk.
this tends to be the most visible when llvm trunk is hundreds or thousands commits ahead of releases.
A few years ago we had this situation :
mesa-git & llvm-svn were maintained by the same person.
mesa-git depended on llvm/llvm-libs.
I maintained mesa-radeon-git and built against llvm-svn / llvm-libs-svn.
Users of mesa-radeon-git (including myself) didn't have much problems.
Users of mesa-git that build against repo llvm had a lot more problems.
When that person stepped down as maintainer (fall of 2015) I took over mesa-git and Kerberizer took over llvm-svn.
Kerberizer agreed with my assessment that mesa-git should be built against llvm-svn , not llvm.
for almost 4 years mesa-git has been depending on llvm-svn with great success.
If I were to adjust mesa-git to built against extra/llvm, I would add a conflict with llvm trunk.
TL;DR : llvm trunk should be treated as a different version of llvm then the latest released version.
Disclaimer: The above is based on my years of experience as user, builder and maintainer of mesa-git.
If I am wrong, please show me proof.
Can you show me the diff that you would have between a PKGBUILD compiling against llvm-svn and one compiling against llvm? I need this to assess what to do in this situation.
Regards, Bruno
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.
On 16-04-2019 18:28, Bruno Pagani wrote:
Can you show me the diff that you would have between a PKGBUILD compiling against llvm-svn and one compiling against llvm? I need this to assess what to do in this situation.
Regards, Bruno
Diff against most recent upload
$ diff --unified --text PKGBUILD PKGBUILD.stable --color --- PKGBUILD 2019-04-17 00:33:05.000000000 +0200 +++ PKGBUILD.stable 2019-04-17 00:38:03.029521485 +0200 @@ -15,11 +15,11 @@ pkgver=19.1.0_devel.110021.c4478889b71 pkgrel=1 arch=('x86_64') -makedepends=('git' 'python-mako' 'llvm-git' 'clang-git' 'xorgproto' +makedepends=('git' 'python-mako' 'llvm' 'clang' 'xorgproto' 'libxml2' 'libx11' 'libvdpau' 'libva' 'elfutils' 'libomxil-bellagio' 'libxrandr' 'ocl-icd' 'vulkan-icd-loader' 'libgcrypt' 'wayland' 'wayland-protocols' 'meson') depends=('libdrm' 'libxxf86vm' 'libxdamage' 'libxshmfence' 'libelf' - 'libomxil-bellagio' 'llvm-libs-git' 'libunwind' 'libglvnd' 'wayland' 'lm_sensors' 'libclc' 'glslang') + 'libomxil-bellagio' 'llvm-libs' 'libunwind' 'libglvnd' 'wayland' 'lm_sensors' 'libclc' 'glslang') optdepends=('opengl-man-pages: for the OpenGL API man pages') provides=('mesa' 'vulkan-intel' 'vulkan-radeon' 'libva-mesa-driver' 'mesa-vdpau' 'vulkan-driver' 'opencl-mesa' 'opengl-driver' 'opencl-driver') conflicts=('mesa' 'opencl-mesa' 'vulkan-intel' 'vulkan-radeon' 'libva-mesa-driver' 'mesa-vdpau') $
On 16-04-2019 18:26, Eli Schwartz via aur-general wrote:
On 4/16/19 9:19 AM, Lone_Wolf wrote:
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.
Adding instructions to switch PKGBUILD to stable llvm/clang is a good idea.
Switching from mesa to mesa-git is easy, reverting is tricky and not everyone has the insight needed to revert from a package with 1 package() function to a split package with multiple package() functions.
I need to add instructions/explanation for reverting from mesa-git / llvm trunk to mesa/llvm stable.
LW
Le 17/04/2019 à 00:54, Lone_Wolf a écrit :
On 16-04-2019 18:28, Bruno Pagani wrote:
Can you show me the diff that you would have between a PKGBUILD compiling against llvm-svn and one compiling against llvm? I need this to assess what to do in this situation.
Regards, Bruno
Diff against most recent upload
$ diff --unified --text PKGBUILD PKGBUILD.stable --color --- PKGBUILD 2019-04-17 00:33:05.000000000 +0200 +++ PKGBUILD.stable 2019-04-17 00:38:03.029521485 +0200 @@ -15,11 +15,11 @@ pkgver=19.1.0_devel.110021.c4478889b71 pkgrel=1 arch=('x86_64') -makedepends=('git' 'python-mako' 'llvm-git' 'clang-git' 'xorgproto' +makedepends=('git' 'python-mako' 'llvm' 'clang' 'xorgproto' 'libxml2' 'libx11' 'libvdpau' 'libva' 'elfutils' 'libomxil-bellagio' 'libxrandr' 'ocl-icd' 'vulkan-icd-loader' 'libgcrypt' 'wayland' 'wayland-protocols' 'meson') depends=('libdrm' 'libxxf86vm' 'libxdamage' 'libxshmfence' 'libelf' - 'libomxil-bellagio' 'llvm-libs-git' 'libunwind' 'libglvnd' 'wayland' 'lm_sensors' 'libclc' 'glslang') + 'libomxil-bellagio' 'llvm-libs' 'libunwind' 'libglvnd' 'wayland' 'lm_sensors' 'libclc' 'glslang') optdepends=('opengl-man-pages: for the OpenGL API man pages') provides=('mesa' 'vulkan-intel' 'vulkan-radeon' 'libva-mesa-driver' 'mesa-vdpau' 'vulkan-driver' 'opencl-mesa' 'opengl-driver' 'opencl-driver') conflicts=('mesa' 'opencl-mesa' 'vulkan-intel' 'vulkan-radeon' 'libva-mesa-driver' 'mesa-vdpau')
Then I would just depend on the non-git version of llvm/clang, and add a pinned comment tell that people wanting the latest feature should also use llvm-git and clang-git. And eventually a note that mesa must be run and compiled against the same clang/llvm version.
Regards, Bruno
Thanks for all replies.
I've thought about this and think I have found a way that will work for all users.
My idea is to introduce a new environment variable, mesa_use_llvm .
It can have the following values :
1 > use aur llvm-lw-git and co
2 > use aur llvm-git and co
3 > use lordheavy unoffical repo llvm-svn and co
4 > use [extra] llvm and co
If mesa_use_llvm is indefined or something else then 1,2,3,4 fallback to value 1.
In the PKGBUILD I'll use depends+= / makedepends+= to add the correct packages.
Choosing which llvm to built against is then setting an environment variable.
Do you guys and girls think this way is a good idea ?
Lone_Wolf
On Tue, 30 Apr 2019 01:32:58 +0200 Lone_Wolf lonewolf@xs4all.nl wrote:
Thanks for all replies.
I've thought about this and think I have found a way that will work for all users.
My idea is to introduce a new environment variable, mesa_use_llvm .
It can have the following values :
1 > use aur llvm-lw-git and co
2 > use aur llvm-git and co
3 > use lordheavy unoffical repo llvm-svn and co
4 > use [extra] llvm and co
If mesa_use_llvm is indefined or something else then 1,2,3,4 fallback to value 1.
In the PKGBUILD I'll use depends+= / makedepends+= to add the correct packages.
Choosing which llvm to built against is then setting an environment variable.
Do you guys and girls think this way is a good idea ?
Lone_Wolf
No, it's not. You're WAY overcomplicating things. The llvm variants you mention should all "provide" llvm, so you just depend on that and can use whatever you want.
Scimmia
Thanks for speaking freely, scimmia.
The env var idea has been thrown out of the window.
Time to summarize and tally .
Option A. mesa-git depends on llvm trunk and PKGBUILD editing is needed for those that want to build against stable llvm.
Option B. mesa-git depends on llvm stable and those that want to build against llvm trunk need to edit the PKGBUILD.
In 2012 there were many mesa trunk packages in AUR. Over time the next years most disappeared or were merged.
from approx 2014 on 2 popular mesa trunk packages remained : mesa-git by krezji and mesa-radeon-git by me.
A big difference was that mesa-git used option B while mesa-radeon-git used option A.
In august 2015 [1] krezji announced he didn't have time to maintain his packages anymore.
I took over mesa-git, switched mesa-git to option A and submitted a deletion request for my mesa-radeon-git package.
Option A is favored by many post 2015 mesa-git users and myself and acceptable to ESchwartz.
Option B is favored by scimmia, bruno, a mesa developer and atleast 2 mesa-git users that discussed this issue with him.
I don't see a way to combine option A & B in one package but feel i can't ignore the requests for option B.
At this point in time the likely outcome seems that I adjust mesa-git to use option B.
I'll create new packages for option A under a new pkgbase, maybe mesa-lw-git.
Then I'll post a call for a new mesa-git maintainer. I'll keep maintaining both mesa trunk sets of packages for about a month, if no new maintainer for mesa-git is found by then it will become an orphan.
I don't like abandoning a package but I can't maintain something I disagree with.
I'll give myself a few days to think this over before deciding.
Lone_Wolf
[1] https://lists.archlinux.org/pipermail/aur-general/2015-August/031298.html
On Wed, 1 May 2019 01:07:43 +0200 Lone_Wolf lonewolf@xs4all.nl wrote:
Thanks for speaking freely, scimmia.
The env var idea has been thrown out of the window.
Time to summarize and tally .
Option A. mesa-git depends on llvm trunk and PKGBUILD editing is needed for those that want to build against stable llvm.
Option B. mesa-git depends on llvm stable and those that want to build against llvm trunk need to edit the PKGBUILD.
You're still not getting it. The diff you gave shows that the only differences are in the depends and madedepends arrays. If that's the only difference, then there *IS NO DIFFERENCE*. A dep on "llvm-libs" is satisfied by llvm-libs-git, so it works in both cases, just as is intended. There is no editing the PKGBUILD needed by users of either option. That's how "provides" works.
Scimmia
On 01-05-2019 05:18, Doug Newgard via aur-general wrote:
You're still not getting it. The diff you gave shows that the only differences are in the depends and madedepends arrays. If that's the only difference, then there *IS NO DIFFERENCE*. A dep on "llvm-libs" is satisfied by llvm-libs-git, so it works in both cases, just as is intended. There is no editing the PKGBUILD needed by users of either option. That's how "provides" works.
Scimmia
I know how conflicts/provides/replaces work.
It seems I failed to make clear that the major problems I see occur at install and runtime, NOT at buildtime.
Here's another attempt to explain that.
Hypothetical example
Assumptions :
mesa-git depends on llvm and llvm-libs
AUR only has one mesa-git package
User builds in clean chroot with devtools
User wants mesa feature X, finds they need to run mesa-git for that.
User clones aur mesa-git and builds with extra-x86_64-build
makepkg sees llvm / llvm-libs dependencies are satisfied by extra/llvm and extra/llvm-libs.
mesa-git is build against those versions
user installs mesa-git, pacman sees llvm-libs is needed and finds extra/llvm-libs installed.
User runs mesa-git, realizes feature X is not working.
Investigation reveals feature X is not supported by stable llvm, user needs to built mesa-git against llvm-git.
User builds llvm-git + llvm-libs-git in clean chroot.
In order to use the llvm-git for mesa-git building they add the packages manually to extra-x86_64-build.
They now have a mesa-git build against llvm-git and install that.
pacman sees mesa-git depends on llvm-libs , and that's satisfied by extra/llvm-libs.
user tries again , mesa-git crashes.
User asks for help on forum.
Someone that understands how mesa and llvm interact, suggests they try installing llvm-libs-git .
User installs that, mesa-git works and feature X also works .
User is happy, tries to figure out how to avoid similar issues in future.
Someone points out that the mesa-git crash was caused by pacman being unaware which llvm-libs binary version was needed.
Simple solution : edit depends in PKGBUILD to have mesa-git depend on llvm-git / llvm-libs-git .
User stays happy with mesa-git built against llvm trunk and rebuilds every week.
Then mesa-git maintainer adds a patch for a build error.
User clones mesa-git again, re-edits PKGBUILD to keep building against llvm trunk.
A week later mesa devs have solved the build error, mesa-git maintainer removes patch.
User clones mesa-git PKGBUILD, re-edits PKGBUILD again.
A while later User gets tired of having to edit PKGBUILD and decides to create a new AUR package : mesa-git-build-against-llvm-git that hard depends on llvm trunk.
AUR now has 2 mesa-git packages.
Maintainers talk and realise having one mesa-git package that allows building against llvm stable or llvm trunk is very likely to cause confusion and problems.
Mesa-git maintainer will have mesa-git hard depend on specific llvm stable versions, while mesa-git-build-against-llvm-git will continue to hard depend on llvm git .
<end-of-hypothetical-example>
Is that a clear enough explanation why I want mesa-git packages to depend on llvm trunk OR llvm stable and not both ?
Lone_Wolf
On Wed, 1 May 2019 12:38:41 +0200 Lone_Wolf lonewolf@xs4all.nl wrote:
On 01-05-2019 05:18, Doug Newgard via aur-general wrote:
You're still not getting it. The diff you gave shows that the only differences are in the depends and madedepends arrays. If that's the only difference, then there *IS NO DIFFERENCE*. A dep on "llvm-libs" is satisfied by llvm-libs-git, so it works in both cases, just as is intended. There is no editing the PKGBUILD needed by users of either option. That's how "provides" works.
Scimmia
I know how conflicts/provides/replaces work.
It seems I failed to make clear that the major problems I see occur at install and runtime, NOT at buildtime.
Here's another attempt to explain that.
Hypothetical example
Assumptions :
mesa-git depends on llvm and llvm-libs
AUR only has one mesa-git package
User builds in clean chroot with devtools
User wants mesa feature X, finds they need to run mesa-git for that.
User clones aur mesa-git and builds with extra-x86_64-build
makepkg sees llvm / llvm-libs dependencies are satisfied by extra/llvm and extra/llvm-libs.
mesa-git is build against those versions
user installs mesa-git, pacman sees llvm-libs is needed and finds extra/llvm-libs installed.
User runs mesa-git, realizes feature X is not working.
Investigation reveals feature X is not supported by stable llvm, user needs to built mesa-git against llvm-git.
User builds llvm-git + llvm-libs-git in clean chroot.
In order to use the llvm-git for mesa-git building they add the packages manually to extra-x86_64-build.
They now have a mesa-git build against llvm-git and install that.
pacman sees mesa-git depends on llvm-libs , and that's satisfied by extra/llvm-libs.
user tries again , mesa-git crashes.
User asks for help on forum.
Someone that understands how mesa and llvm interact, suggests they try installing llvm-libs-git .
User installs that, mesa-git works and feature X also works .
User is happy, tries to figure out how to avoid similar issues in future.
Someone points out that the mesa-git crash was caused by pacman being unaware which llvm-libs binary version was needed.
Simple solution : edit depends in PKGBUILD to have mesa-git depend on llvm-git / llvm-libs-git .
Full stop. Solution is not to edit the PKGBUILD, solution is for the theoretical user to not be replacing system libraries when they don't have a clue what they're doing.
You're trying to overcomplicate the system to account for user stupidity. This is Arch, stop doing that.
Scimmia
On 5/1/19 10:53 AM, Doug Newgard via aur-general wrote:
On Wed, 1 May 2019 12:38:41 +0200 Lone_Wolf lonewolf@xs4all.nl wrote:
Assumptions :
mesa-git depends on llvm and llvm-libs
AUR only has one mesa-git package
User builds in clean chroot with devtools
User wants mesa feature X, finds they need to run mesa-git for that.
User clones aur mesa-git and builds with extra-x86_64-build
makepkg sees llvm / llvm-libs dependencies are satisfied by extra/llvm and extra/llvm-libs.
mesa-git is build against those versions
user installs mesa-git, pacman sees llvm-libs is needed and finds extra/llvm-libs installed.
User runs mesa-git, realizes feature X is not working.
Investigation reveals feature X is not supported by stable llvm, user needs to built mesa-git against llvm-git.
User builds llvm-git + llvm-libs-git in clean chroot.
In order to use the llvm-git for mesa-git building they add the packages manually to extra-x86_64-build.
They now have a mesa-git build against llvm-git and install that.
pacman sees mesa-git depends on llvm-libs , and that's satisfied by extra/llvm-libs.
user tries again , mesa-git crashes.
User asks for help on forum.
Someone that understands how mesa and llvm interact, suggests they try installing llvm-libs-git .
User installs that, mesa-git works and feature X also works .
User is happy, tries to figure out how to avoid similar issues in future.
Someone points out that the mesa-git crash was caused by pacman being unaware which llvm-libs binary version was needed.
Simple solution : edit depends in PKGBUILD to have mesa-git depend on llvm-git / llvm-libs-git .
Full stop. Solution is not to edit the PKGBUILD, solution is for the theoretical user to not be replacing system libraries when they don't have a clue what they're doing.
You're trying to overcomplicate the system to account for user stupidity. This is Arch, stop doing that.
I'm still not really seeing what the problem here is.
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.
It's not unreasonable to want the resulting package to have technically correct dependency linkages when its compilation environment results in *different dependencies*.
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".
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.
On Fri, 3 May 2019 10:04:39 -0400 Eli Schwartz via aur-general aur-general@archlinux.org wrote:
On 5/1/19 10:53 AM, Doug Newgard via aur-general wrote:
On Wed, 1 May 2019 12:38:41 +0200 Lone_Wolf lonewolf@xs4all.nl wrote:
Assumptions :
mesa-git depends on llvm and llvm-libs
AUR only has one mesa-git package
User builds in clean chroot with devtools
User wants mesa feature X, finds they need to run mesa-git for that.
User clones aur mesa-git and builds with extra-x86_64-build
makepkg sees llvm / llvm-libs dependencies are satisfied by extra/llvm and extra/llvm-libs.
mesa-git is build against those versions
user installs mesa-git, pacman sees llvm-libs is needed and finds extra/llvm-libs installed.
User runs mesa-git, realizes feature X is not working.
Investigation reveals feature X is not supported by stable llvm, user needs to built mesa-git against llvm-git.
User builds llvm-git + llvm-libs-git in clean chroot.
In order to use the llvm-git for mesa-git building they add the packages manually to extra-x86_64-build.
They now have a mesa-git build against llvm-git and install that.
pacman sees mesa-git depends on llvm-libs , and that's satisfied by extra/llvm-libs.
user tries again , mesa-git crashes.
User asks for help on forum.
Someone that understands how mesa and llvm interact, suggests they try installing llvm-libs-git .
User installs that, mesa-git works and feature X also works .
User is happy, tries to figure out how to avoid similar issues in future.
Someone points out that the mesa-git crash was caused by pacman being unaware which llvm-libs binary version was needed.
Simple solution : edit depends in PKGBUILD to have mesa-git depend on llvm-git / llvm-libs-git .
Full stop. Solution is not to edit the PKGBUILD, solution is for the theoretical user to not be replacing system libraries when they don't have a clue what they're doing.
You're trying to overcomplicate the system to account for user stupidity. This is Arch, stop doing that.
I'm still not really seeing what the problem here is.
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.
It's not unreasonable to want the resulting package to have technically correct dependency linkages when its compilation environment results in *different dependencies*.
No different than an soname bump.
Le 03/05/2019 à 16:04, Eli Schwartz via aur-general a écrit :
On 5/1/19 10:53 AM, Doug Newgard via aur-general wrote:
On Wed, 1 May 2019 12:38:41 +0200 Lone_Wolf lonewolf@xs4all.nl wrote:
Assumptions :
mesa-git depends on llvm and llvm-libs
AUR only has one mesa-git package
User builds in clean chroot with devtools
User wants mesa feature X, finds they need to run mesa-git for that.
User clones aur mesa-git and builds with extra-x86_64-build
makepkg sees llvm / llvm-libs dependencies are satisfied by extra/llvm and extra/llvm-libs.
mesa-git is build against those versions
user installs mesa-git, pacman sees llvm-libs is needed and finds extra/llvm-libs installed.
User runs mesa-git, realizes feature X is not working.
Investigation reveals feature X is not supported by stable llvm, user needs to built mesa-git against llvm-git.
User builds llvm-git + llvm-libs-git in clean chroot.
In order to use the llvm-git for mesa-git building they add the packages manually to extra-x86_64-build.
They now have a mesa-git build against llvm-git and install that.
pacman sees mesa-git depends on llvm-libs , and that's satisfied by extra/llvm-libs.
user tries again , mesa-git crashes.
User asks for help on forum.
Someone that understands how mesa and llvm interact, suggests they try installing llvm-libs-git .
User installs that, mesa-git works and feature X also works .
User is happy, tries to figure out how to avoid similar issues in future.
Someone points out that the mesa-git crash was caused by pacman being unaware which llvm-libs binary version was needed.
Simple solution : edit depends in PKGBUILD to have mesa-git depend on llvm-git / llvm-libs-git .
Full stop. Solution is not to edit the PKGBUILD, solution is for the theoretical user to not be replacing system libraries when they don't have a clue what they're doing.
You're trying to overcomplicate the system to account for user stupidity. This is Arch, stop doing that.
I'm still not really seeing what the problem here is.
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?
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.
Bruno
On 03/05/2019 17:23, Bruno Pagani via aur-general wrote:
Le 03/05/2019 à 16:04, Eli Schwartz via aur-general a écrit :
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.
It refers to the email from Lone_Wolf that proposed an env variable that will at build time generate/manipulate deps by inspecting the system.
Bruno
I am a bit baffled by this thread.
I understand we have standards and requirements and suggestions and best practices and so on, but for the Arch User Repository - is Lone_Wolf not allowed to make a package called 'my-awesome-mesa-git-that-uses-llvm-git-and-thats-final'? And as long as it builds, installs safe, runs fine, **fulfils a purpose**, **doesn't have an equivalent** and **does not abuse the website or users**, then all we can do is say 'Good Job'?
This is both a genuine question and a personal surprise if it is otherwise.
As for the general **good** way of doing this, we already know to do it - we either have a single person in charge of the whole stack and each release is binary consistent or we communicate and sync our builds/releases. Why not just make sure/trust Lone_Wolf that they will do their part as maintainer and check for all dependencies and provide version bumps and prompt updates, etc as any good maintainer will?
Regards, Konstantin
On Fri, May 03, 2019 at 06:00:32PM +0300, Konstantin Gizdov wrote:
I understand we have standards and requirements and suggestions and best practices and so on, but for the Arch User Repository - is Lone_Wolf not allowed to make a package called 'my-awesome-mesa-git-that-uses-llvm-git-and-thats-final'? And as long as it builds, installs safe, runs fine, **fulfils a purpose**, **doesn't have an equivalent** and **does not abuse the website or users**, then all we can do is say 'Good Job'?
Well no, it has to be usefull for more then just a few people.
'my-personal-highly-specialized-llvm-git-package' won't necessarily be allowed. If this is the case for this package I have no clue, have not followed the thread that closely.
"Make sure the package you want to upload is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission."
https://wiki.archlinux.org/index.php/Arch_User_Repository#Rules_of_submissio...
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.
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
On 5/3/19 11:25 AM, Bruno Pagani wrote:
Yes, and he can solves that by *pinning a comment telling so*. ;)
Pinning a comment telling people how to get the default expected User Experience in a non-default way, sucks.
The package maintainer thinks that the average user will dislike the resulting default default user experience, will experience crashes, will experience missing features, etc. -- and as a result the package maintainer has *flatly* refused under any and all circumstances to continue maintaining the package that he has, apparently, been maintaining to many peoples' satisfaction, for the last four years.
Apparently, he *really* thinks that that is a bad idea and an inferior mesa-git experience.
On Fri, 3 May 2019 11:32:57 -0400 Eli Schwartz via aur-general aur-general@archlinux.org wrote:
On 5/3/19 11:25 AM, Bruno Pagani wrote:
Yes, and he can solves that by *pinning a comment telling so*. ;)
Pinning a comment telling people how to get the default expected User Experience in a non-default way, sucks.
The package maintainer thinks that the average user will dislike the resulting default default user experience, will experience crashes, will experience missing features, etc. -- and as a result the package maintainer has *flatly* refused under any and all circumstances to continue maintaining the package that he has, apparently, been maintaining to many peoples' satisfaction, for the last four years.
Apparently, he *really* thinks that that is a bad idea and an inferior mesa-git experience.
And apparently the mesa developers disagree. Remember how this thread started.
On 5/3/19 11:41 AM, Doug Newgard via aur-general wrote:
On Fri, 3 May 2019 11:32:57 -0400 Eli Schwartz via aur-general aur-general@archlinux.org wrote:
Apparently, he *really* thinks that that is a bad idea and an inferior mesa-git experience.
And apparently the mesa developers disagree. Remember how this thread started.
This logic is automatically invalid, no ifs ands or buts.
Upstream developers *by definition* have different priorities from downstream users. Furthermore, the world is full of projects run by upstreams who have unrealistic and sometimes ridiculous expectations; anyone who has packaged a lot of software should know this.
If the mesa developers disagree, that's fine. But it doesn't actually mean anything. What would mean something is their rationale for disagreeing. Just like any other upstream software.
So far all I've seen are vague, shadowy statements being thrown around, and a whole lot of judging going on based on these shadowy statements. That's not good enough for me to accept "but muh authority as upstream dev" as an instant-win argument which refutes all comers.
On Tue, 7 May 2019 13:42:05 -0400 Eli Schwartz via aur-general aur-general@archlinux.org wrote:
On 5/3/19 11:41 AM, Doug Newgard via aur-general wrote:
On Fri, 3 May 2019 11:32:57 -0400 Eli Schwartz via aur-general aur-general@archlinux.org wrote:
Apparently, he *really* thinks that that is a bad idea and an inferior mesa-git experience.
And apparently the mesa developers disagree. Remember how this thread started.
This logic is automatically invalid, no ifs ands or buts.
Your argument is that is makes for an unacceptable mesa experience. The experience intended by upstream is EXTREMELY valid.
Upstream developers *by definition* have different priorities from downstream users. Furthermore, the world is full of projects run by upstreams who have unrealistic and sometimes ridiculous expectations; anyone who has packaged a lot of software should know this.
If the mesa developers disagree, that's fine. But it doesn't actually mean anything. What would mean something is their rationale for disagreeing. Just like any other upstream software.
So how upstream intends their software to work doesn't mean anything? Try again.
Le 03/05/2019 à 17:32, Eli Schwartz a écrit :
On 5/3/19 11:25 AM, Bruno Pagani wrote:
Yes, and he can solves that by *pinning a comment telling so*. ;)
Pinning a comment telling people how to get the default expected User Experience in a non-default way, sucks.
Not “the default”. LW’s vision of default. And apparently not necessarily upstream one since all this started because an upstream dev asked for the other use case to be published.
The package maintainer thinks that the average user will dislike the resulting default default user experience, will experience crashes, will experience missing features, etc. -- and as a result the package maintainer has *flatly* refused under any and all circumstances to continue maintaining the package that he has, apparently, been maintaining to many peoples' satisfaction, for the last four years.
Apparently, he *really* thinks that that is a bad idea and an inferior mesa-git experience.
I still think that you would get a better user experience even for this case by telling the users explicitely that this depends on llvm-git. Because else, people would install mesa-git once, which will pull llvm-git as a dependency and build it for this only time, and any subsequent user update of mesa-git to get newer features might results in this sub-par experience he seems afraid of because gradually their installed llvm-git will get old if they don’t realize they need to update both. That’s why I’m against any sort of PKGBUILD imposed dep on a -git package without a pinned comment telling why. And the only way to be sure that the user will read it if they use the -git dependency, is either that this dependency is absolutely required (because e.g. it does not compile without it or does not run, in which cases listing it in depends is OK), or that they have to read this first to realize they can and maybe should swap the standard dep with the -git one.
Bruno
On 5/3/19 11:44 AM, Bruno Pagani wrote:
I still think that you would get a better user experience even for this case by telling the users explicitely that this depends on llvm-git. Because else, people would install mesa-git once, which will pull llvm-git as a dependency and build it for this only time, and any subsequent user update of mesa-git to get newer features might results in this sub-par experience he seems afraid of because gradually their installed llvm-git will get old if they don’t realize they need to update both. That’s why I’m against any sort of PKGBUILD imposed dep on a -git package without a pinned comment telling why. And the only way to be sure that the user will read it if they use the -git dependency, is either that this dependency is absolutely required (because e.g. it does not compile without it or does not run, in which cases listing it in depends is OK), or that they have to read this first to realize they can and maybe should swap the standard dep with the -git one.
What, people install multiple -git packages, but then refuse to ever update them unless they were installed with --asexplicit? I literally cannot fathom that idea, and have never heard of such a notion. I've heard of people who would leave them both not-updated, though.
I don't believe anyone will ever do as you fear.
Le 03/05/2019 à 18:29, Eli Schwartz via aur-general a écrit :
On 5/3/19 11:44 AM, Bruno Pagani wrote:
I still think that you would get a better user experience even for this case by telling the users explicitely that this depends on llvm-git. Because else, people would install mesa-git once, which will pull llvm-git as a dependency and build it for this only time, and any subsequent user update of mesa-git to get newer features might results in this sub-par experience he seems afraid of because gradually their installed llvm-git will get old if they don’t realize they need to update both. That’s why I’m against any sort of PKGBUILD imposed dep on a -git package without a pinned comment telling why. And the only way to be sure that the user will read it if they use the -git dependency, is either that this dependency is absolutely required (because e.g. it does not compile without it or does not run, in which cases listing it in depends is OK), or that they have to read this first to realize they can and maybe should swap the standard dep with the -git one.
What, people install multiple -git packages, but then refuse to ever update them unless they were installed with --asexplicit? I literally cannot fathom that idea, and have never heard of such a notion. I've heard of people who would leave them both not-updated, though.
I don't believe anyone will ever do as you fear.
They came for mesa-git, did not took care about which dependency were pulled. They update mesa-git, but don’t think of llvm-git because they were never informed this is especially relevant for mesa-git.
Other case : user already has llvm-git for whatever reason, but like you said don’t update it (they forgot about it, don’t care…). They install mesa-git from AUR, llvm-git dependency is already satisfied. But at that point, their llvm-git could even be older than repo llvm (granted, at this stage they would have other issues). So depending on llvm-git in mesa-git does not achieve a lot.
I have decided how to proceed with mesa trunk / llvm trunk building.
There are now 6 lone_wolf-* packages in AUR that show how I want to do things.
Although Scimmia intensely disliked it, I have implemented the environment variable idea in lone_wolf-mesa-git .
First tests are promising, I could succesfully build mesa trunk against stable llvm with this command :
lone_wolf_use_llvm=4 makepkg -Crs
After some more testing I'll use the same method in lone_wolf-lib32-mesa-git .
Whether those PKGBUILDs will be used in future aur mesa-git , exclusively in aur lone_wolf-* packages or not present in AUR at all is a decision TUs must take.
I uploaded my first AUR package somewhere in 2006 and would hate to have to take my packages elsewhere.
However TUs have always been the people that administer AUR not the users. IF TUs tell me my packages are not wanted in AUR I have to follow my own personal standards and remove the packages.
Waiting for a decision, Lone_Wolf
Quoting Lone_Wolf (2019-05-04 18:24:28)
I have decided how to proceed with mesa trunk / llvm trunk building.
There are now 6 lone_wolf-* packages in AUR that show how I want to do things.
Although Scimmia intensely disliked it, I have implemented the environment variable idea in lone_wolf-mesa-git .
First tests are promising, I could succesfully build mesa trunk against stable llvm with this command :
lone_wolf_use_llvm=4 makepkg -Crs
After some more testing I'll use the same method in lone_wolf-lib32-mesa-git .
Whether those PKGBUILDs will be used in future aur mesa-git , exclusively in aur lone_wolf-* packages or not present in AUR at all is a decision TUs must take.
I uploaded my first AUR package somewhere in 2006 and would hate to have to take my packages elsewhere.
However TUs have always been the people that administer AUR not the users. IF TUs tell me my packages are not wanted in AUR I have to follow my own personal standards and remove the packages.
Waiting for a decision, Lone_Wolf
https://lists.archlinux.org/pipermail/aur-requests/2019-May/031274.html
https://lists.archlinux.org/pipermail/aur-requests/2019-May/031310.html
v_v
-- Best, Daniel https://danielcapella.com
On 05-05-2019 00:39, Daniel M. Capella via aur-general wrote:
f https://lists.archlinux.org/pipermail/aur-requests/2019-May/031274.html
https://lists.archlinux.org/pipermail/aur-requests/2019-May/031310.html
v_v
-- Best, Daniel https://danielcapella.com
The 031274 message was an overreaction by me, but I should have added more test to the new request.
Creating 6 new packages and making sure they build takes time, when I submitted the new merge requests I had little time left.
Here's a long version :
The old scheme was pkgname_without_git-lw-git . It looked confusing and wasn't clear enough.
By changing to lone_wolf-$pkgname the name scheme looks a lot more consistent and the package is clearly linked to my aur/forum nick.
I tried to think of clearer naming but couldn't find a way to do that in less then 8 words, which would make the package names consist of 10 to 12 words.
In my opinion lone_wolf-$pkgname is the best compromise between clarity and brevity.
Thanks for the reminder, Daniel .
Lone
On 5/5/19 12:24 AM, Lone_Wolf wrote:
I have decided how to proceed with mesa trunk / llvm trunk building.
There are now 6 lone_wolf-* packages in AUR that show how I want to do things.
Although Scimmia intensely disliked it, I have implemented the environment variable idea in lone_wolf-mesa-git .
First tests are promising, I could succesfully build mesa trunk against stable llvm with this command :
lone_wolf_use_llvm=4 makepkg -Crs
After some more testing I'll use the same method in lone_wolf-lib32-mesa-git .
Whether those PKGBUILDs will be used in future aur mesa-git , exclusively in aur lone_wolf-* packages or not present in AUR at all is a decision TUs must take.
I uploaded my first AUR package somewhere in 2006 and would hate to have to take my packages elsewhere.
However TUs have always been the people that administer AUR not the users. IF TUs tell me my packages are not wanted in AUR I have to follow my own personal standards and remove the packages.
Waiting for a decision, Lone_Wolf
Rules of Submission[1]
Make sure the package you want to upload is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.
A package so specialized that you have to prefix it with your username because you cannot think of anything more useful does not comply with this rule, fwiw.
[1] https://wiki.archlinux.org/index.php/Arch_User_Repository#Rules_of_submissio...
On 06-05-2019 11:57, Robin Broda via aur-general wrote:
Rules of Submission[1]
Make sure the package you want to upload is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.
A package so specialized that you have to prefix it with your username because you cannot think of anything more useful does not comply with this rule, fwiw.
[1] https://wiki.archlinux.org/index.php/Arch_User_Repository#Rules_of_submissio...
Quoting myself :
On 05-05-2019 00:24, Lone_Wolf wrote:
Whether those PKGBUILDs will be used in future aur mesa-git , exclusively in aur lone_wolf-* packages or not present in AUR at all is a decision TUs must take.
If no decision has been reached by june 3, I'll submit deletion requests for those 6 packages myself.
LVV
On 5/6/19 12:28 PM, Lone_Wolf wrote:
Quoting myself :
On 05-05-2019 00:24, Lone_Wolf wrote:
Whether those PKGBUILDs will be used in future aur mesa-git , exclusively in aur lone_wolf-* packages or not present in AUR at all is a decision TUs must take.
If no decision has been reached by june 3, I'll submit deletion requests for those 6 packages myself.
LVV
What decision is there to be reached by anyone?
I am a TU and I merely quoted a page off our Wiki to you.
Going by that "rule", I don't think lone_wolf-* packages have a place in the AUR. Unless you can figure out a better, fitting name.
As it stands i still don't see how these pkgbuilds solve anything. Now, instead of editing one word in the PKGBUILD you supply an env var...
On 06-05-2019 12:37, Robin Broda via aur-general wrote:
On 5/6/19 12:28 PM, Lone_Wolf wrote:
Quoting myself :
On 05-05-2019 00:24, Lone_Wolf wrote:
Whether those PKGBUILDs will be used in future aur mesa-git , exclusively in aur lone_wolf-* packages or not present in AUR at all is a decision TUs must take.
If no decision has been reached by june 3, I'll submit deletion requests for those 6 packages myself.
LVV
What decision is there to be reached by anyone?
I am a TU and I merely quoted a page off our Wiki to you.
Going by that "rule", I don't think lone_wolf-* packages have a place in the AUR. Unless you can figure out a better, fitting name.
As it stands i still don't see how these pkgbuilds solve anything. Now, instead of editing one word in the PKGBUILD you supply an env var...
It seems I overreacted and hijacked my own thread.
I also made several mistakes and may have (unintentionally) offended people.
I apoligise to all posters in & readers of this thread.
There are decisions that need to be made, but I'm the one that needs to make them , not TUs.
I do need to do some serious thinking and will keep radiosilence during the thinking.
Some unfinished business :
Robin, you do have a valid point about lone_wolf-* not being good package names.
If my creativity is not enough to chose good names, I should ask help with picking names instead of choosing bad ones.
The question this thread started with is still valid
Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?
Lone_Wolf
I have some serious thinking to do
Em maio 7, 2019 14:00 Lone_Wolf escreveu:
It seems I overreacted and hijacked my own thread.
I also made several mistakes and may have (unintentionally) offended people.
I apoligise to all posters in & readers of this thread.
There are decisions that need to be made, but I'm the one that needs to make them , not TUs.
I do need to do some serious thinking and will keep radiosilence during the thinking.
Some unfinished business :
Robin, you do have a valid point about lone_wolf-* not being good package names.
If my creativity is not enough to chose good names, I should ask help with picking names instead of choosing bad ones.
The question this thread started with is still valid
Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?
This thread went way beyond what it should have gone. This is the AUR we're talking about. I'm not saying we should accept any crap on the AUR, but, I'm talking from my own experience here, we don't always anticipate what will be useful or not to people.
I have several packages I've put on the AUR that, even though I've followed the guidelines, I didn't expect them to be of any use to other people. And yet, they did. On the other hand, I have uploaded packages that I expected to be of use, and they turned out to not be that useful.
Unless we have a way to enforce the guidelines properly, I say that we should not bikeshed this much over AUR submissions. We have a lot of crap on AUR, yes. We have a lot of submissions that are useful to only one person, yes. We have packages that are not even for the architecture we support, yes. So, let's not dabble over a package that's not even the worse we have on the AUR *right now*.
Regards, Gincarlo Razzolini
On 5/7/19 1:13 PM, Giancarlo Razzolini via aur-general wrote:
This thread went way beyond what it should have gone. This is the AUR we're talking about. I'm not saying we should accept any crap on the AUR, but, I'm talking from my own experience here, we don't always anticipate what will be useful or not to people.
In fact, the AUR is sort of by definition a place for people to experiment with software.
I have several packages I've put on the AUR that, even though I've followed the guidelines, I didn't expect them to be of any use to other people. And yet, they did. On the other hand, I have uploaded packages that I expected to be of use, and they turned out to not be that useful.
Unless we have a way to enforce the guidelines properly, I say that we should not bikeshed this much over AUR submissions. We have a lot of crap on AUR, yes. We have a lot of submissions that are useful to only one person, yes. We have packages that are not even for the architecture we support, yes. So, let's not dabble over a package that's not even the worse we have on the AUR *right now*.
Yeah, I think it is pretty disheartening that someone who has capably packaged software for years is receiving so much flak over how he does it, when everyone agrees that it's definitely useful to a whole bunch of random ordinary users.
Because apparently ideological purity in the AUR. Even though no one can actually suggest a better way of doing it that answers the thought-provoking usability concerns which have been raised.
On 5/6/19 6:37 AM, Robin Broda via aur-general wrote:
I merely quoted a page off our Wiki to you.
Going by that "rule", I don't think lone_wolf-* packages have a place in the AUR. Unless you can figure out a better, fitting name.
I think "mesa-git" is probably fine.
As it stands i still don't see how these pkgbuilds solve anything. Now, instead of editing one word in the PKGBUILD you supply an env var...
We could always go back to the initial suggestion of editing one word in the PKGBUILD, which works pretty well for a number of other packages, last I checked. I mean, we do assume users read the PKGBUILD before executing untrusted code, right?
On 5/3/19 1:09 PM, Bruno Pagani wrote:
They came for mesa-git, did not took care about which dependency were pulled. They update mesa-git, but don’t think of llvm-git because they were never informed this is especially relevant for mesa-git.
If they break their system by installing packages from git, and not updating them, then that is entirely on their head.
Other case : user already has llvm-git for whatever reason, but like you said don’t update it (they forgot about it, don’t care…). They install mesa-git from AUR, llvm-git dependency is already satisfied. But at that point, their llvm-git could even be older than repo llvm (granted, at this stage they would have other issues). So depending on llvm-git in mesa-git does not achieve a lot.
Like I said? What I said is that they *will* update it.
If they don't update it but do install mesa-git, and then don't update that either, then as you even point out, they have other issues. And what I will point out, is that they are not the intended users of the AUR. Responsible people who use the AUR as intended, are the intended users of the AUR.
So yes, depending on llvm-git does achieve a lot. It achieves a state of being, whereby competent users who read the instructions, know what is on their system, and act responsibly, build some package against current development versions of llvm, tracking code that is far ahead of [extra]/llvm.
On Tue, 7 May 2019 13:42:16 -0400 Eli Schwartz via aur-general aur-general@archlinux.org wrote:
On 5/3/19 1:09 PM, Bruno Pagani wrote:
They came for mesa-git, did not took care about which dependency were pulled. They update mesa-git, but don’t think of llvm-git because they were never informed this is especially relevant for mesa-git.
If they break their system by installing packages from git, and not updating them, then that is entirely on their head.
Which negates the maintainers entire argument.
aur-general@lists.archlinux.org