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

[Balló György]

2014/1/22 Xyne <xyne at 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