| Summary: | app-eselect/eselect-python should maintain pkgconfig symlinks | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | David E. Narváez <david.narvaez> |
| Component: | Current packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | gentoo, jkt, mgorny |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
David E. Narváez
2013-03-19 12:36:29 UTC
First of all, there's no relevance between your proposal and the one you try to refer to. The functions there need to access specific Python implementation, not a random eselected one. Secondly, pkg-config files are not a playground. You want a new pkg-config file, take it to upstream. We won't invent something like that or in a few months people will have random packages failing on other distros because a few lazy folks started to rely on this. (In reply to comment #1) > Secondly, pkg-config files are not a playground. You want a new pkg-config > file, take it to upstream. We won't invent something like that or in a few > months people will have random packages failing on other distros because a > few lazy folks started to rely on this. Upstream's relevant installation part is as follows: # Install the interpreter by creating a symlink chain: # $(PYTHON) -> python2 -> python$(VERSION)) # Also create equivalent chains for other installed files bininstall: altbininstall [...] -test -d $(DESTDIR)$(LIBPC) || $(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$(LIBPC) -rm -f $(DESTDIR)$(LIBPC)/python2.pc (cd $(DESTDIR)$(LIBPC); $(LN) -s python-$(VERSION).pc python2.pc) -rm -f $(DESTDIR)$(LIBPC)/python.pc (cd $(DESTDIR)$(LIBPC); $(LN) -s python2.pc python.pc) So your argument is the other way around: packages that work in other distros fail in Gentoo because it is missing the default layout. In fact, unless you use Gentoo-specific tools you are unable to answer the basic question of "what's the python configuration?" which is the whole point of this enhancement. If that is so, let's re-consider this. As a side note, arch doesn't do 'python.pc' either. One potential issue I see here is that we're introducing one additional point of failure -- since packages are not allowed to rely upon non-specific pkg-config files in Gentoo. We can wrap executables and even python-config to respect EPYTHON -- but I don't see how we could really wrap pkg-config files without doing something quite ugly. And since I don't think we can/should do something like that by default, we're likely to end up with packages which query the wrong Python version and nobody notices for a while since it's the default one. (In reply to comment #4) > One potential issue I see here is that we're introducing one additional > point of failure -- since packages are not allowed to rely upon non-specific > pkg-config files in Gentoo. > > We can wrap executables and even python-config to respect EPYTHON -- but I > don't see how we could really wrap pkg-config files without doing something > quite ugly. And since I don't think we can/should do something like that by > default, we're likely to end up with packages which query the wrong Python > version and nobody notices for a while since it's the default one. Are you referring to the case when, e.g., a user switches to Python 3.x as the default Python and builds a package that only works in Python 2.x? Or the case when a user builds packages with the correct version and later switches Python versions and things stop working? (In reply to comment #5) > (In reply to comment #4) > > One potential issue I see here is that we're introducing one additional > > point of failure -- since packages are not allowed to rely upon non-specific > > pkg-config files in Gentoo. > > > > We can wrap executables and even python-config to respect EPYTHON -- but I > > don't see how we could really wrap pkg-config files without doing something > > quite ugly. And since I don't think we can/should do something like that by > > default, we're likely to end up with packages which query the wrong Python > > version and nobody notices for a while since it's the default one. > > Are you referring to the case when, e.g., a user switches to Python 3.x as > the default Python and builds a package that only works in Python 2.x? This one but in a more general version. Let's suppose user has 2.7+3.2 enabled -- the default values. Package foo supports both so should be built against both. But the build system just queries 'pkg-config python', so it gets whatever Python version was eselected. We end up having to work hard to work-around this. (In reply to comment #6) > Let's suppose user has 2.7+3.2 enabled -- the default values. Package foo > supports both so should be built against both. But the build system just > queries 'pkg-config python', so it gets whatever Python version was > eselected. We end up having to work hard to work-around this. Ok, I see your point and I can't say I totally disagree. Yet, I'd argue that a packager can epatch that to be 'pkg-config python$(python_get_version --major)' which would work perfectly regardless of what's the eselection at emerge time. eselect-python won't do this. For package builds, the eclasses already create necessary symlinks. *** Bug 900907 has been marked as a duplicate of this bug. *** |
