Bug 414955 – Portage should undefine FEATURES inside ebuilds

• Product: Portage Development
• Status: CONFIRMED ---

[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 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 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 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 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 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 (RETIRED) 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 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!