search

rafspiny / enlightenment-live

Enlightenment WM latest stable version and live ebuilds
9 stars 4 forks source link

add ${PYTHON_USEDEP} to dependencies #61

Closed waebbl closed 5 years ago

waebbl commented 5 years ago

I was trying to install the enlightenment-apps-9999 set today, which felt on python-efl. I noticed that the ebuild for it, and also the ebuild for packages depending on it lack the ${PYTHON_USEDEP} variable on python related dependencies. This got the deps calculation wrong and some packages, e.g. cython weren't installed with the right settings. The patches below fixes this issue, so I was able to install the set.

Note, that I haven't touched the PYTHON_COMPAT variable. This contains values, which are no longer supported on gentoo (e.g. python3_4 support). Because I didn't know, whether this repo might also be used on gentoo descendants or other gentoo-like distros, I left the variable alone.

rafspiny commented 5 years ago

@waebbl Thanks for the PR.

It looks good, but I am wondering if you can make few adjustments:

waebbl commented 5 years ago

@rafspiny I can look into this.

Which ebuild.badheader do you mean? On my 5 commits, I fixed the headers and don't get any ebuild.badheader warning. Those come from other packages, e.g. dev-util/enventor, which I haven't touched.

I see what I can do with the net-p2p/epour ebuild to fix the dependency.badmasked warnings. Would it be ok, to remove obsolete targets, like python-3.4 and replace obsolete pypy2_0 by pypy?

Edit: I checked the complete repo, badheaders are in dev-libs/efl, dev-util/enventor and x11-wm/enlightenment. Touching dev-libs/efl seems not reasonable, while you're at it porting it to meson, but I can fix the headers on the other two and add them to the commit stack.

Edit 2: Would you mind, if I update those ebuilds to EAPI 7 while at it?

waebbl commented 5 years ago

I would suggest to remove the dead implementations from PYTHON_COMPAT. If you look at https://github.com/gentoo/gentoo/blob/master/app-portage/gpyutils/files/implementations.txt you see, that only python2_7, python3_{5,6,7} and pypy{,3} are currently supported for any Gentoo installation, no matter which arch. So there's not really the need to have dead implementations like python2_6, python3_2 or pypy2_0 in this variable. Partly those might have to do with the dependency.badmasked errors from repoman.

waebbl commented 5 years ago

I fixed the ebuild headers for dev-util/enventor and x11-wm/enlightenment. Other changes are coming later.

waebbl commented 5 years ago

Also please note, the badheader warnings seems to be related to your outdated portage version in .travis.yml. You're using 2.3.4x, while current is 2.3.67. This version is possibly dated back to before Gentoo introduced GLEP 76 and the change of the copyright line.

rafspiny commented 5 years ago

@waebbl Thanks for all the feedback!

Touching dev-libs/efl seems not reasonable, while you're at it porting it to meson,

Indeed. I count to have time to work on the efl meson build this weekend.

I would suggest to remove the dead implementations from PYTHON_COMPAT

Agreed.

You're using 2.3.4x, while current is 2.3.67

It should definitely be upgraded.

@waebbl Thanks again for your enthusiasm and willingness to contribute.

waebbl commented 5 years ago

@rafspiny Dropping the dead python implementations introduces a bunch of new dependency.badmasked warnings, notably on python-efl but also on upstream dbus-python. IMO the simplest solution would be to have all (python related) ebuilds in the overlay support the same set of python implementations, i.e. python3_{5,6,7} and possibly pypy{,3}. I never used pypy though, so I first have to test this in a chroot.

waebbl commented 5 years ago

I completely dropped the pypy support, because pypy is globally masked for current profiles. You need profile 13.0 to use pypy, which is no longer available for any of the arches. See also https://github.com/gentoo/gentoo/blob/master/profiles/arch/base/use.mask#L182 for this. Now that the 13.0 profiles have been tree cleaned, I suspect that pypy support will also go soon.

I now only have the ebuild.badheader warning from dev-libs/efl left. Additionally I get a fatal error from repoman,

  EAPI.definition [fatal]       1
   media-gfx/ephoto/ephoto-1.5.ebuild: bash returned EAPI '7' which does not match assignment on line: 4

The reason for this is, there's an ephoto-1.5 ebuild in the main tree, which uses EAPI 7 already and also has another (updated) SRC_URI which refers to an official enlightenment download area, instead of pointing to a private homepage. Maybe you want to completely drop the ephoto-1.5.ebuild in favor of the Gentoo tree ones and only keep the ephoto-9999.ebuild around?

I'm going to push now for your reference and then bumping the above ebuilds to EAPI 7.

rafspiny commented 5 years ago

@waebbl Thank you so much for stepping up and help me with this. About ephoto, I completely agree with you on the fact that ebuild for 1.5 should go from the overlay.

I am gonna merge it later this weekend. Again, thank you so much.

waebbl commented 5 years ago

@rafspiny You're welcome. I'd like to have working and up-to-date enlightenment available :) I just pushed the bumps to EAPI 7. I build-tested all of them on my machine, but there's only python-2.7 and 3.6 available. I also build-tested most of them, with the exception of python-efl and espionage inside an amd64 chroot against all supported python versions. The two I couldn't test depend on =dev-libs/efl-9999.