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