Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

Lone_Wolf
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
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
On Tue, 16 Apr 2019 15:19:37 +0200
Lone_Wolf <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
In reply to this post by Lone_Wolf
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
Reply | Threaded
Open this post in threaded view
|

Re: 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 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
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
In reply to this post by Lone_Wolf
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


signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
In reply to this post by 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.
>
>
> 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.

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
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

Lone_Wolf
In reply to this post by tur-users mailing list
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



Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

Lone_Wolf
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
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
On Tue, 30 Apr 2019 01:32:58 +0200
Lone_Wolf <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

Lone_Wolf
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
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
On Wed, 1 May 2019 01:07:43 +0200
Lone_Wolf <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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 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
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
On Wed, 1 May 2019 12:38:41 +0200
Lone_Wolf <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
On 5/1/19 10:53 AM, Doug Newgard via aur-general wrote:

> On Wed, 1 May 2019 12:38:41 +0200
> Lone_Wolf <[hidden email]> 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.

--
Eli Schwartz
Bug Wrangler and Trusted User


signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
On Fri, 3 May 2019 10:04:39 -0400
Eli Schwartz via aur-general <[hidden email]> 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
In reply to this post by tur-users mailing list
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

Konstantin Gizdov
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



signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
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_submission

--
Morten Linderud
PGP: 9C02FF419FECBE16

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

tur-users mailing list
In reply to this post by tur-users mailing list
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


signature.asc (1K) Download Attachment
12