On 3/14/20 7:20 AM, Samuel Bernardo wrote: > Hi again, > > As a suggestion, I would propose for each overlay to override the eclass > functions for those necessary to EAPI 6 within their ebuilds.
Yes, either do that or upgrade EAPI in the ebuilds. > For instance, go-overlay could use old eclasses that support EAPI 6 > overriding the current ones. For some reason they updated their eclasses > to EAPI 7 before updating the ebuilds. Apparently the go-overlay sabotaged itself with this commit: https://github.com/Dr-Terrible/go-overlay/commit/2b5bfa01bf8777f28f57eb5b7da2ccde4ace744b#diff-2e747d04b1138fffb99dbb6a5fdd6c1b > This brings me to the main issue that is the portage cache and possible > conficts between those eclass defined in the overlay and those from > gentoo main stream. Maybe a name convention would be useful here for > future upgrades as a code styling guide for gentoo developers. There's no conflict. Overlays are free to override eclasses as needed. > What do you think about this kind of issues? It's not a good idea for overlays to make eclass changes that break their own ebuilds. > Best, > > Samuel > > On 12/03/2020 10.42, Samuel Bernardo wrote: >> Hi, >> >> Is there any way to allow EAPI 6 for some overlays with current portage >> stable version (2.3.89-r1)? The portage version is irrelevant. All versions of portage are backward compatible with all old EAPIs. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
