Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 414955 - Portage should undefine FEATURES inside ebuilds
Summary: Portage should undefine FEATURES inside ebuilds
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on: 415045
Blocks: preserve-libs
  Show dependency tree
 
Reported: 2012-05-06 22:15 UTC by Ciaran McCreesh
Modified: 2012-12-25 20:59 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ciaran McCreesh 2012-05-06 22:15:10 UTC
Portage should undefine FEATURES when inside an ebuild so that people can't write abusive code that tries to make use of it.
Comment 1 Zac Medico gentoo-dev 2012-05-06 22:20:39 UTC
Yeah, we can migrate internal code to use the existing PORTAGE_FEATURES variable:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c32aee053541993a3b7be732798976ed20faba69
Comment 2 Mike Gilbert gentoo-dev 2012-05-06 23:19:46 UTC
Would it also be unset for eclass code? Just thinking of the preserve_old_lib function from eutils.eclass.
Comment 3 Zac Medico gentoo-dev 2012-05-06 23:23:21 UTC
(In reply to comment #2)
> Would it also be unset for eclass code?

Yes, of course.

> Just thinking of the preserve_old_lib function from eutils.eclass.

It could use PORTAGE_FEATURES instead. :-)
Comment 4 Ciaran McCreesh 2012-05-07 12:59:51 UTC
So you'll need to make sure you don't export PORTAGE_FEATURES to ebuilds too then.
Comment 5 Zac Medico gentoo-dev 2012-05-07 16:49:58 UTC
Maybe we should add a function like preserve_old_lib in the package manager for EAPI 5.
Comment 6 Ciaran McCreesh 2012-05-07 16:55:38 UTC
Maybe we should put slot operator deps in EAPI 5 so you don't need any of that flaky mess.
Comment 7 Zac Medico gentoo-dev 2012-05-07 16:59:04 UTC
Slot operator deps are nice, but you also have to make people promise to stop using preserve_old_lib then.
Comment 8 Arfrever Frehtes Taifersar Arahesis 2012-05-07 17:01:02 UTC
soname changes can occur inside the same slot.
Comment 9 Ciaran McCreesh 2012-05-07 17:02:52 UTC
(In reply to comment #7)
> Slot operator deps are nice, but you also have to make people promise to
> stop using preserve_old_lib then.

That's easy. Deprecate it, ban it in newer EAPIs, and then later remove it.

(In reply to comment #8)
> soname changes can occur inside the same slot.

Which is why you use another slot when that happens, and use slot operator deps to handle the dependency. There is absolutely no need to match slots to versions in any way.
Comment 10 Tiziano Müller gentoo-dev 2012-05-07 18:58:23 UTC
I really hate preserve_libs, but what is the proper solution for packages like mpfr which change the soname but upstream does not version the headers?

I see four possibilities:
1) patch them to version the headers as well and slot them (together with slot operator deps)
2) ask upstream to properly version the headers alongside with the lib and slot them (together with slot operator deps)
3) slot them and block old slots in newer versions (together with slot operator deps)
4) introduce a new EAPI variable which can be incremented whenever an soname changes (needs some more thinking and proper specification, somehow duplicates SLOT)
Comment 11 Ciaran McCreesh 2012-05-07 19:08:55 UTC
Those are all possibilities. You can also subdivide packages (possibly using use flags) into "the bits that need to be kept around for a while" and "the rest".
Comment 12 Zac Medico gentoo-dev 2012-06-06 02:07:01 UTC
(In reply to comment #10)
> 4) introduce a new EAPI variable which can be incremented whenever an soname
> changes (needs some more thinking and proper specification, somehow
> duplicates SLOT)

That's the ABI_SLOT variable mentioned in bug 192319, comment #18. It would make slot operator deps much more flexible. Let's do it in EAPI 5!