[aur-requests] [PRQ#28274] Deletion Request for petalinux-v2020.1

[Christopher Snowhill (kode54)]

> On Sep 22, 2021, at 12:03 AM, Amin Vakil via aur-requests <aur-requests at lists.archlinux.org> wrote:
> 
> On 9/21/21 20:58, Alex Henrie wrote:
>>> On Tue, Sep 21, 2021 at 12:01 AM Amin Vakil <info at aminvakil.com> wrote:
>>> 
>>> On 9/20/21 20:38, Alex Henrie wrote:
>>>> On Sat, Sep 18, 2021 at 12:19 AM <notify at aur.archlinux.org> wrote:
>>>>> 
>>>>> aminvakil [1] filed a deletion request for petalinux-v2020.1 [2]:
>>>>> 
>>>>> https://aur.archlinux.org/packages/petalinux-v2021.1/ is already
>>>>> present.
>>>>> 
>>>>> [1] https://aur.archlinux.org/account/aminvakil/
>>>>> [2] https://aur.archlinux.org/pkgbase/petalinux-v2020.1/
>>>> 
>>>> I'm surprised that petalinux-v2020.1, petalinux-v2020.2, and
>>>> petalinux-v2020.3 were deleted from the AUR. It would be nice to have
>>>> the older versions in the AUR because the latest version (2021.1) is
>>>> not 100% compatible. And the AUR has lots of old versions of other
>>>> packages like gcc-arm-none-eabi-bin, so why not petalinux?
>>>> 
>>>> $ yay -Ssq gcc-arm-none-eabi
>>>> gcc-arm-none-eabi-bin-92
>>>> gcc-arm-none-eabi-bin-83
>>>> gcc-arm-none-eabi-bin-63
>>>> gcc-arm-none-eabi-bin-72
>>>> gcc-arm-none-eabi-bin-73
>>>> gcc-arm-none-eabi-bin-102
>>>> gcc-arm-none-eabi-bin-93
>>>> gcc-arm-none-eabi-bin-49
>>>> gcc-arm-none-eabi-bin-82
>>>> gcc-arm-none-eabi-bin
>>> 
>>> Thanks for bringing this up, I've submitted deletion requests for all of
>>> them as well.
>> Are you going to delete all the old versions of GCC for x86 too
>> (gcc34, gcc43, gcc44, gcc45, gcc46, gcc47, gcc48, gcc49, gcc5, gcc53,
>> gcc6, gcc7, gcc8, gcc9)? And if so, why? gcc10 was even promoted out
>> of the AUR.
>> -Alex
> 
> Arch Wiki is very clear about this:
> https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission
> 
> The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.
> 
> "If any version of it exists, do not submit the package."
> 
> But I think gcc is a specific case which I will not get involved in submitting a deletion request for it, but I have asked about it in #archlinux-aur channel on Libera to see what are others' opinions.
> 
> - Amin Vakil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1EFC1864E9D9E56B.asc
Type: application/octet-stream
Size: 2479 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-requests/attachments/20210922/875b1572/attachment-0001.obj>
-------------- next part --------------

I'd say the same also applies to any dependency for an aur package that doesn't work with the latest version. May I even go so far as to suggest there should be zero legacy version packages, even if the latest is only an aur package? Drop mongodb44 too, old computers serve no purpose, much like old software.





Huge /s btw