[aur-general] Python split packages and devtools

Fabien Dubosson fabien.dubosson at gmail.com
Sat Nov 21 16:03:54 UTC 2015


Hi,

I like to build my AUR packages within a chroot by using
`extra-x86_64-build` from the `devtools` package for some reasons:

  1. I usually build only once my packages and share them between my
     machines. For this, the package shouldn't link against libraries
     that are found on the machine because they are not always available
     on the other ones.

  2. It's *a little bit* more safe as the code is executed within a
     chroot, AFAIK.

  3. When creating/developing packages, I'm sure that all dependencies
     are included.

I created a `python-keras-git` package, that is a split package with
both python2 and python3 version of it [1]. Someone pointed me out that
because of my `make-depends`, people has to have both python2 and
python3 installed to build only the desired version of the package, what
is true.

But in another way, if I remove this make-depends, then
`extra-x86_64-build` script can no build the package any longer, as it
needs python to build the package (for using `python setup.py …`)

So here are some questions:

  - If I choose one of `python` or `python2` to build the package,
    people having the other will have to install it also. (and I don't
    know if python-setuptools can build also for python2 or vice-versa?)
  - If I put both, people will have to install the one they don't have.
  - If I don't define a make-depends, the PKGBUILD is not complete.
  - It doesn't seem possible to put the make-depends inside the
    `pakages_<pkgname>()` function, isn't it?

What is the right/best way of achieving this?

Thanks,
Fabien

[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=python-keras-git
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20151121/88fa8a72/attachment.asc>


More information about the aur-general mailing list