2014/1/22 Xyne <x...@archlinux.ca>: > On 2014-01-21 02:31 -0600 > Doug Newgard wrote: > >>> Most of the packages get better over time and in my case, it's not >>> possible to have 140 packages in perfect state at once. So I can perfectly >>> update or fix 4 packages/day (sometimes more if I automatically scan for >>> new releases >>> with pkgcheck :)), but some require community feedback/discussion, >>> some need upstream fixes or further time for debugging. >>> For the most part, the packages were in a much worse state than today. >>> In my opinion the AUR is something like a incubator for new, >>> experimental or less popular packages. If I havent put an early >>> unfinished version of Gitlab [1] into the AUR, I wouldn't have been able >>> to get that many constructive feedback and at the same time write an >>> instruction at the wiki [2]. I guess the diversity is the reason, why the >>> AUR is >>> such a popular feature of ArchLinux. Of course there are more stable, less >>> experimental packages which I want to see in the community repository. >>> >>> [1] https://aur.archlinux.org/packages/gitlab/ >>> [2] https://wiki.archlinux.org/index.php/Gitlab >> >>Ok, so let's look at just that one. >> >>What are "Unconfirmed makedeps"? Are they makedeps or aren't they? >> >>You set the backup array based on what is installed at build time, which has >>little to do with what is installed at install/run time. This works (somewhat) >>in the AUR but not at all in binary repos. Not only that, but you then set a >>new >>backup array right after it making the whole thing moot. >> >>You pull a bunch of files directly from master of a git repo. Very fragile. >> >>Your quoting of paths containing variables is very inconsistent, some are >>quoted >>then not quoted in the next line. >> >>Your use of curly braces is inconsistent. >> >>Sometimes you use mv, sometimes cp, and sometimes install. Why? >> >>Again, you're installing things based on what is installed at build time. >> >>That's from a cursory reading of your given example, without looking into it >>in >>detail or looking at the install file at all. You see what I mean? Many TUs >>have >>as many or more packages than you're talking about, and they're all expected >>to >>be in good shape. > > I'm randomly scanning your AUR packages and so far I keep seeing things that I > don't like just as the previous posters have mentioned (missing package > functions, outdated PKGBUILD templates, lack of quotes, cd'ing into the > SRCDEST > directory (why?), etc.). > > There are some nice PKGBUILDs there but so far the majority of what I have > seen > has been of poor quality. Most of us (the TUs) probably have at least one or > two > sub-standard PKGBUILDs lying around waiting to get flagged and updated, but > overall there should be consistent quality. > > You should have made an effort to correct at least the trivial PKGBUILDs prior > to submitting your application. You should also have addressed the > flagged packages (as you allegedly agreed you would with your sponsor). > > I don't want to discourage you from further contribution but I do not think > that you are ready to be a TU. You should take some time to address the issues > raised in this thread and then spend at least a few more months maintaining > your packages. Orphan some if you cannot adequately manage all of them. > Quality > counts for far more than quantity. > > Regards, > Xyne
I agree with Xyne. You have to learn some more things and clean up your packages before you are ready. I commented some of your packages in AUR. E.g. libzrtp, zfone and zfoned install files into the /usr/local directory, which is forbidden by a package. -- György Balló Trusted User
