Thanks for the clarification. Cheers, Daniel
Jonathan Steel <[email protected]> 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.
