[arch-dev-public] Decisions on AUR management - Was: RFC: Forbid dummy packages from AUR

Allan McRae allan at archlinux.org
Thu Mar 24 11:24:03 UTC 2022


On 24/3/22 18:42, Brett Cornwall via arch-dev-public wrote:
> On 2022-03-24 13:23, Allan McRae via arch-dev-public wrote:
>> On 24/3/22 11:07, Brett Cornwall via arch-dev-public wrote:
>>> A new RFC (request for comment) has been opened here:
>>>
>>> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/12
>>>
>>> Please visit the above link for discussion.
>>>
>>> Summary: Reject AUR packages that fulfill package dependencies 
>>> without providing the files/binaries of the package in question.
>>
>>
>> Just a query if this crosses the line into to distro policy (i.e. RFC 
>> Land) from TU self-governing policy land?  I'm OK with this being 
>> discussed as an RFC (openness and visibility is good), but my initial 
>> reaction was this could have been discussed "internally" by the 
>> maintainers of the AUR (TUs) using aur-general.
> 
> This proposal was brought up on #archlinux-tu and I was encouraged to 
> create an RFC. Perhaps I was mistaken in thinking that the AUR was a 
> project of Arch:
> 
 >> A Request for Comment (RFC) is a way for Arch Linux contributors to
 >> propose, design and discuss new features and changes in project
 >> direction in a focused environment.

From:
https://github.com/archlinux/tu-bylaws/blob/master/tu-bylaws.adoc

Mission: #2
"Maintain, manage, and watch over the operation of the AUR."

This proposal sounds like a management of the AUR issue.

> I can withdraw this but I'd advise clarification that TUs should go 
> huddle in another corner for future discussion. Perhaps another repo for 
> TU rfcs would be welcome if this is the case.

Again, from the TU bylaws:

"Standard Voting Procedure (SVP) describes the formal procedure used by 
TUs to accept or reject proposals regarding TU affairs."

TUs have a process to follow already.  A separate RFC repo would require 
TU Bylaw changes.


Currently, it is unclear to me whether accepting an RFC still requires a 
TU vote for the policy to be accepted.  With that uncertainty, I put 
more weight on the side with formal bylaws.

As I said, I'm happy the discussion around this RFC is public and open. 
But if this is a big enough change for an RFC, then it almost certainly 
needs to go through the TU voting procedure.

Allan


More information about the arch-dev-public mailing list