[ Copying aur-general for other opnions and get clarification on AUR rules out there ]
Hey Jonathan,
Thanks for maintaining AUR and keeping the Arch ecosystem healthy. Some honest questions/comments regarding the deletion of the AUR package customizepkg-ald:
The package was a patched version of customizepkg. There are thousands of AUR packages that are variants of other packages and I can't see any problem with that. In my understanding that's part of what AUR is for. Is it not?
It's been customary for AUR deletions, orphanings etc. to have a two weeks grace period. Should that not also apply to TUs?
The .tar.gz that you mentioned that violated the "no binaries on AUR" rule contained nothing but ASCII files (as does customizepk¹). If I unzip the tarball and re-upload it, does that not violate the rule? What if I also untar it and upload each text file individually?
Cheers, Daniel
¹ https://aur.archlinux.org/packages/customizepkg/
On Di, 2014-11-25 at 18:52 +0000, notify@aur.archlinux.org wrote:
from https://aur.archlinux.org//pkgbase/customizepkg-ald/ jsteel wrote:
Ah, I just realised this is an intentional duplicate of customizepkg; please don't submit duplicate packages, submit an orphan request instead. Deleting.
If you no longer wish to receive notifications about this package, please go the the above package page and click the UnNotify button.
On Tue 25 Nov 2014 at 23:13, Daniel Albers wrote:
[...] There are thousands of AUR packages that are variants of other packages and I can't see any problem with that. In my understanding that's part of what AUR is for. Is it not?
It's been customary for AUR deletions, orphanings etc. to have a two weeks grace period. Should that not also apply to TUs?
The .tar.gz that you mentioned that violated the "no binaries on AUR" rule contained nothing but ASCII files (as does customizepk¹). If I unzip the tarball and re-upload it, does that not violate the rule? What if I also untar it and upload each text file individually? [...]
I am generally conservative when it comes to package deletions, but I saw this as having two big problems; being a duplicate of another AUR package, and including the tarball.
The PKGBUILD was identical (apart from a version bump and pkgname/pkgbase).
The package was a patched version of customizepkg.
You must have included a modified tarball then, as there were no patches.
If you want to fork the project then host the source elsewhere; then it will not be seen as a duplicate package. The AUR is not for hosting projects, but for providing build files for packages.
Thanks for the clarification.
Cheers, Daniel
Jonathan Steel mail@jsteel.org schrieb am 26.11.2014:
On Tue 25 Nov 2014 at 23:13, Daniel Albers wrote:
[...] There are thousands of AUR packages that are variants of other
packages
and I can't see any problem with that. In my understanding that's
part
of what AUR is for. Is it not?
It's been customary for AUR deletions, orphanings etc. to have a two weeks grace period. Should that not also apply to TUs?
The .tar.gz that you mentioned that violated the "no binaries on AUR" rule contained nothing but ASCII files (as does customizepk¹). If I unzip the tarball and re-upload it, does that not violate the rule?
What
if I also untar it and upload each text file individually? [...]
I am generally conservative when it comes to package deletions, but I saw this as having two big problems; being a duplicate of another AUR package, and including the tarball.
The PKGBUILD was identical (apart from a version bump and pkgname/pkgbase).
The package was a patched version of customizepkg.
You must have included a modified tarball then, as there were no patches.
If you want to fork the project then host the source elsewhere; then it will not be seen as a duplicate package. The AUR is not for hosting projects, but for providing build files for packages.
aur-general@lists.archlinux.org