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

[Doug Newgard]

----------------------------------------
> Date: Tue, 21 Jan 2014 07:38:25 +0000
> From: onny at project-insanity.org
> To: aur-general at archlinux.org
> Subject: Re: [aur-general] TU application, sponsored by Lukas Fleischer
>
> On 01-20 17:55, Doug Newgard wrote:
>> ----------------------------------------
>>> Date: Mon, 20 Jan 2014 23:32:08 +0000
>>> From: onny at project-insanity.org
>>> To: aur-general at archlinux.org
>>> Subject: [aur-general] TU application, sponsored by Lukas Fleischer
>>>
>>> Hi ArchLinux community,
>>> I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack),
>>> since my passion and work for ArchLinux continues since half a decade
>>> and I really would like to get more involved into development and
>>> package maintaining.
>>> My name is Jonas (my public key [1]), I'm 23 years old, computer science
>>> student in Karlsruhe, Germany. I switched to Linux in school while
>>> working voluntarily on a school server [2] and school internet cafe
>>> together with a class mate in our free time. Hacking on fun projects
>>> became on of my big hobbies and some of them are documented in my blog
>>> [3]. I get a lot of inspiration and exchange in my local hacker space,
>>> the Entropia e.V. [4] which is part of the CCC (Chaos Computer Club) [5]
>>> but also at work as a network administrator at the architecture faculty
>>> of my university.
>>> I love ArchLinux, using it on my servers (with several ArchLinux vms)
>>> and on my laptop, because it's simple, basic and fast. The wiki is also
>>> one of my favorite places in the community, because all the
>>> documentation is pragmatic and to the point. I constantly write new
>>> how-to's or improve instructions on other pages [6]. In my opinion, a
>>> well written Wiki/Doku, also for all the third-party software, is very
>>> important and one reason why I don't want to use Debian anymore for my
>>> projects.
>>> I learned how to write clean and sometimes complex PKGBUILDs over time
>>> and now maintaining up to 150 AUR packages [7]. Some of them are really
>>> important to me (using them on my server or integrated them to my
>>> projects) and I think also important to the community, so I would like
>>> to put them into the community repository. For example: archivemount,
>>> btar, dmtcp, etherpad-lite, freecad, gallery, gitlab, hlds, joomla,
>>> opentracker, pyload, python-libtorrent-rasterbar, sslstrip, etc. For
>>> other packages, I adopted them just to fix broken PKGBUILDs or I tried
>>> to port non-supported software to ArchLinux like Zenoss, oVirt or Kolab
>>> while working with their developers to improve ArchLinux support.
>>> At least, here are some of my experimental projects you can look at:
>>> p2pacman [8], pkgcheck [9], wikidict [10], carpc based on ArchLinux
>>> [11].
>>> For further questions, you can find me on #archlinux at freenode or just
>>> ask them here on the mailinglist.
>>> Best regards,
>>> Jonas
>>>
>>> [1] http://onny.project-insanity.org/files/gpg.asc
>>> [2]
>>> http://www.project-insanity.org/blog/2010/06/03/dokumentation-zur-einrichtung-des-schulserver-fur-die-freie-waldorfschule-vaihingenenz/
>>> (text unfortunately in German)
>>> [3] http://project-insanity.org
>>> [4] https://entropia.de
>>> [5] https://en.wikipedia.org/wiki/Chaos_Computer_Club
>>> [6] https://wiki.archlinux.org/index.php/Special:Contributions/Onny
>>> [7] https://aur.archlinux.org/packages/?K=onny&SeB=m
>>> [8] https://bbs.archlinux.org/viewtopic.php?id=163362
>>> [9] https://bbs.archlinux.org/viewtopic.php?id=162816
>>> [10] https://git.morbi-happens.de/onny/wikidict
>>> [11]
>>> http://www.project-insanity.org/blog/2012/10/10/archlinux-touchscreen-carpc-mit-xbmc-frontend/
>>
>> I'm a nobody, so my opinion probably doesn't count, but if you can't properly
>> maintain the package you already have the AUR, why do you want to take on more
>> responsibility? A quick look shows packages marked out of date, one for nearly
>> 10 months (flamerobin), packages with fixes posted in the comments months ago
>> that you haven't implemented (libappindicator), VCS packages with useless
>> pkgver() functions (most of your -git packages), and packages with no package()
>> function (vim-paster and others). So help me out here, what would make you a
>> good TU?
> 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.