[aur-general] TU Application - György Balló
lists at baums-on-web.de
Thu Mar 1 14:29:16 EST 2012
Am Thu, 01 Mar 2012 19:00:52 +0100
schrieb Balló György <ballogyor at gmail.com>:
> I currently have 150 packages in AUR with a total of 5775 votes. I
> already maintain more than 200 packages as source packages on
> github and as built i686 packages in my [ayatana] repo. I don't
> want to move all of these packages to [community], only the popular
> ones. I always try to make the best packages and I hate poorly
> written PKGBUILDs.
I have just some concerns regarding the quality of your PKGBUILDs as
You have a lot of split packages with this very dirty workaround
true && pkgname=(subpackage1 subpackage2 subpackage3)
uploaded to AUR, even if AUR and the AUR wrappers like yaourt don't
support split packages.
And some of your packages depend on subpackages of those split
packages, which is the reason that all those packages can't be
installed at least not with the AUR wrappers because they can't find
those subpackages on AUR.
And there are such very weird dependencies in some of your PKGBUILD like
true && depends=('libindicator3>=0.3.19' 'libindicate>=0.4.90'
which totally doesn't make sense and again causes problems.
See e.g. these packages and their dependencies:
And your package naming is at least sometimes inconsistent like this
This implies that it's built against GTK2 and that the GTK2 and only
the GTK2 version is installed. In fact this package installs the GTK2
version and the GTK3 version by having indicator-messages, which builds
and installs the GTK3 version, unnecessarily as a dependency.
I'm not a TU, but I would expect a much better packaging quality from
a user whom I can trust instead of such a mess.
The package indicator-messages as it is now definitely can't be
installed by yaourt and most likely (I haven't tested this, yet) not
even by makepkg.
And I'm absolutely not able to relate to your arguments for this.
Btw., how do you want to be a TU and do this work if you tell me that
you're maintaining so many packages that you have no time to write and
maintain single packages instead of those split packages on AUR which
are officially supported by AUR and would easily be installable by the
Of course, in [community] you can officially build split packages. But,
as you've written you want to keep most of your packages in AUR.
So I'm very concerned about your applications. But I don't have to
decide about that.
More information about the aur-general