[arch-dev-public] RFC: Forbid dummy packages from AUR
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.
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. Allan
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.
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.
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
On Thu, Mar 24, 2022 at 09:24:03PM +1000, Allan McRae via arch-dev-public wrote:
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.
I'd be happy with having this proposal going through the RFC process and later go through the TU voting if the RFC gets accepted. That seems like a fair compromise to me? -- Morten Linderud PGP: 9C02FF419FECBE16
participants (3)
-
Allan McRae
-
Brett Cornwall
-
Morten Linderud