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
|

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

--
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 11:32:57 -0400
Eli Schwartz via aur-general <[hidden email]> 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.
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 à 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
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/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.

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

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 ?

Lone_Wolf
On 05-05-2019 00:39, Daniel M. Capella via aur-general wrote:

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

--
Rob (coderobe)

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


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 ?

Lone_Wolf

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

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

--
Rob (coderobe)

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


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 ?

Lone_Wolf

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

attachment0 (887 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 11:41 AM, Doug Newgard via aur-general wrote:
> On Fri, 3 May 2019 11:32:57 -0400
> Eli Schwartz via aur-general <[hidden email]> 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.

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


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

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

--
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 tur-users mailing list
On Tue, 7 May 2019 13:42:05 -0400
Eli Schwartz via aur-general <[hidden email]> 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 <[hidden email]> 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.
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 Tue, 7 May 2019 13:42:16 -0400
Eli Schwartz via aur-general <[hidden email]> 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.
12