On Wed, May 6, 2026 at 21:10:16 CST, Amin Vakil wrote:
> On 5/6/26 12:12 PM, George Hu wrote:
>
> > On 5/6/26 4:10 PM, George Hu wrote:
> >
> >
> >> On 5/6/26 3:59 PM, George Hu wrote:
> >>
> >>
> >>
> >>> On 5/6/26 2:07 PM, DeepChirp wrote:
> >>>
> >>>
> >>>
> >>>> Hello everyone,
> >>>>
> >>>>
> >>>>
> >>>> I am DeepChirp ("深鸣" in Chinese). Sponsored by Felix Yan and
> >>>> George Hu (in alphabetical order), I'm writing this email to
> >>>> apply
> >>>> to become an Arch Linux Package Maintainer.
> >>>
> >>>
> >>>
> >>> I also confirm my sponsorship.
> >>> He demonstrated keen enthusiasm and a willingness to contribute
> >>> while
preparing his application. I am confident he will be a
> >>> valuable team member.
> >>>
> >>>
> >>
> >>
> >>
> >> I forgot to include my signature in the last email; this message
> >> includes it.
> >
> >
> > Since both sponsors have confirmed their sponsorship, we can start
> > the
two-week discussion period which will end on 2026-05-20.
> >
>
> Hi everyone!
>
> Is having a package like code-xdg-dir-patch allowed? It manages same
> files as code package (I know it does it by purpose), but isn't is
> against some AUR rules?
>
> Best Regards,
> Amin VakilHi Amin, Thanks for bringing this up! I've double-checked the AUR submission guidelines, and there doesn't seem to be any explicit rule against this type of package. This package doesn't directly claim ownership of `code`'s tracked files in the `package()` function. Instead, it uses ALPM hooks to apply the patch after the official `code` package is updated. Furthermore, `code-marketplace`, `code-features`, and `vscodium-xdg-dir- patch` on the AUR employ a similar approach. All of them have received a significant number of votes, which I believe reflects the utility of these packages to users. However, within the official Arch Linux repositories, we should adhere to the default behavior of upstream software. Therefore, I believe we should not patch packages to enable XDG support; instead, such patches should be hosted on the AUR, where users who require them can access them. Hope this clarifies the situation! Best Regards, DeepChirp
signature.asc
Description: This is a digitally signed message part.
