On Tue, Aug 23, 2016 at 10:38 PM, Levente Polyak <anthraxx@archlinux.org> wrote:
On August 23, 2016 3:11:55 PM GMT+02:00, Chi Hsuan Yen via aur-general < aur-general@archlinux.org> wrote:
At first I used split packages for python-* packages in my AUR repo. However, since pacman commit e8deba3b87784ca14c9afc908046f36a3ad7578c, [1][2] there's no way to build a subset of split packages. That is, people who use Python 3 (or Python 2) only need to install both Python versions to build my package. It would be nice if I can use a single PKGBUILD and build only a subset of split packages with makepkg.
Effectively (without any intend to blame or offend you) but you are very aware of this and simply ignore it on purpose.
Its not really ideal to not use split packages just because you don't want people who build it to install both variants of the dependencies. If people don't want those in your/their system, then you/they should build it in a chroot (which I recommend either way).
Using clean chroots is definitely the best way to build a package, while it may not be practical for ordinary users. Installing a chroot takes quite a few minutes, lots of network usage and several hunders of megabytes, which is a high burden if I just need a package with 1MB.
I get your point but I still recommend unifying those into a split package and conform decisions that are made. I don't see where building both variants is too much of a hassle. Those should be optimized in a way to be as sane related to structuring and building as possible and not how convenient it is to install it via wrapper X directly out of the AUR.
Others may not agree, but for me making things easy to use is as important as making things clean. With that in mind, I always try my best to keep my AUR packages building fine in clean chroots as well as "dirty" systems with numerous unnecessary packages.
It should be considered more like a staging area for the regular repositories, following its rules. It's always a hassle to invest a day before being able to move a package from the AUR just because they follow something else like not using split packages etc.
cheers, Levente
Not quite agree. How AUR works is different from how official repositories do. How packages are installed is an important factor in those differences.