On 2014-08-05 04:03, LoneVVolf wrote:
On 04-08-14 18:03, Eduardo Machado wrote:
This actually makes sense to me. Most people will only want one version or the other of the lib, depending on what software is using it. Having it as a split package forces them to build both and have all the deps for both installed. Makes sense in a binary repo, not so much in the AUR.
I thinked just liked this after i built these packages, and therefore, i discovered that some of then aren' t compatible with python2 and python3, two of then are python2 only, so i had to comment some lines to hide the python3 part. but i thought this was a bad solution to only keep the script ready for python3 compatibility.
I just built the python-argparse split package in less than three seconds. Build time isn't a valid argument here. Also, I highly recommend building all AUR packages inside a chroot; otherwise, you have no control of what happens on your file system (think of broken build scripts that ignore $(DESTDIR) etc.)
I think it is a good idea to use split packages unless there are good reasons not to do so. Note that the AUR can also be viewed as a staging area for source packages that might eventually be moved to the official repositories. Not using split packages means more work for Trusted Users and developers when moving.
Thinking this way you are right.
Personally i don't mind to work with one or another spec. But i would like the advise of yours to standardize this "trade of". ;)
Nobody is forced to build everything in a split package. Aur packages are meant to be build with makepkg, and it's --pkg option allows you to select which packages of a split package will be build.
If aur helpers don't support that functionality, register a bug report with their maintainers.
LVV
The --pkg option doesn't do anything for dependencies or the build function. You'd still be forced to download and install py3 in order to make a py2 package unless you edit the PKGBUILD manually.