[aur-general] TU Application - György Balló

Heiko Baums lists at baums-on-web.de
Thu Mar 1 15:16:28 EST 2012


Am Thu, 01 Mar 2012 21:46:41 +0200
schrieb Ionut Biru <ibiru at archlinux.org>:

> Most GTK2 GTK3 ports are hard to be supported in AUR since most of the
> time it depends on what packages a user has installed on his system
> and may be picked different because almost 99% of our users do not
> compile in clean chroots.

Why is it hard to support a pure GTK3 port and a pure GTK2 port of a
package in AUR?

Just create one package indicator-messages with a ./configure and
one package indicator-messages-gtk2 with a ./configure --with-gtk=2.

That's so simple. There's really no reason to having indicator-messages
(the GTK3 port) as a dependency for indicator-messages-gtk2 (the GTK2
port). In fact a user expects to just having the GTK2 port being
installed if he installs the -gtk2 packge.

In this case he explained that both ports share some files, and that
there are people who want to have installed both ports at the same
time. This is either no problem.

There are two ways of doing this:
Create one package indicator-messages-base which contains the shared
files, one package indicator-messages-gtk2 and one package
indicator-messages-gtk3.

Or:
Create one package indicator-messages which contains both the GTK2 and
the GTK 3 port if there are really people who want to have both at the
same time, one package indicator-messages-gtk2 and one package
indicator-messages-gtk3.

Pretty easy and gives very clean, officially supported PKGBUILDs which
can easily be installed with makepkg as well as the AUR wrappers.

And what does this have to do with a compilation in a clean chroot?
Nothing. It's just bad packaging.

> Having support for that is hard because AUR needs to understand split
> packages and return them using json interface
> 
> I don't recall AUR having support for those and that's why he needs to
> add workarounds.

No, he doesn't need to add such workarounds. As long as AUR doesn't
support split packages PKGBUILDs just can be written as single packges.

Adding such dirty workarounds to AUR packages is even bad packaging.
Where's the problem to just create either one single PKGBUILD which
builds and installs every feature (subpackage) or to create several
single PKGBUILDs for each subpackage? I don't see any problems. And this
was clean and good packaging which is absolutely and officially
supported by AUR and the AUR wrappers. And such packages can flawlessly
be installed. His packages with those dirty workarounds just can't
be installed. It's definitely not possible to install indicator-messages
with yaourt.

In fact I would recommend to patch AUR, so that it detects and declines
PKGBUILDs with such workarounds, if AUR won't be patched to support
split packages.

Heiko


More information about the aur-general mailing list