[aur-general] Clarification for Deletion request #30701

[Xyne]

On 2022-01-01 21:24 +0300
Caleb Maclennan via aur-general wrote:

>On 2022-01-01 14:48, Doug Newgard via aur-general wrote:
>> On Sat, 1 Jan 2022 05:33:08 +0100  
>>> * All packages built from pre-compiled sources in the AUR should 
>>> retain the
>>>   "-bin" suffix to indicate this, without exception.  
>> 
>> Packages that cannot be built from source have always been an exception 
>> here,
>> are you proposing to eliminate that? It makes little sense to have a 
>> -bin
>> package when there cannot be a non-bin version.  
>
>Doug is right that there has always been an exception here. The rule to 
>date as I've understood it is that the package must be suffixed with 
>-bin if the source is available whether a package exists or not, but 
>many closed source packages have been exceptions.
>
>That being said I would fully support a proposition to make this a 
>requirement for *all* binary packages whether source is available or 
>not.
>
>We should probably make that issue it's own thread because it really 
>isn't the same issue as whether -bin packages should be deleted if repo 
>builds are available.

I actually would be in favor of using the -bin suffix even for packages without
a non-bin variant. It makes the origin of the binaries clear to the user and
may even draw further attention to the fact that upstream is not releasing
buildable sources, which is something that we should at least gently encourage.
It also avoids renaming packages if and when buildable sources become available.

This is just my personal preference though and I admit that I had not
considered the case when I replied. I'm not really opposed to the exception
"unless source code is unavailable".

I hadn't considered the kernel packages in the AUR either. On further
consideration I really don't know what's best. Whatever rules we decide, the
goal is to make the AUR as useful as possible. linux-ck and linux-mainline are
clearly popular and thus useful so I do not propose removing them. But I still
don't think that we should allow multiple variants of the same package that do
nothing more than change a few build options. The difficulty is clearly
defining the difference between a trivial modification and one that is involved
enough that it is preferable to have a dedicated package.

We could use popularity as a criterion for allowing a variant, but that
requires some arbitrary thresholds of votes and time. Or we could just allow
all variants. The important thing is that the rules are applied uniformly.

Regards,
Xyne