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.
