[aur-general] TU application, sponsored by Lukas Fleischer

[Xyne]

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