On Tue, Sep 6, 2016 at 9:02 PM, Erik Mackdanz <stasib...@gentoo.org> wrote: > Kristian Fiskerstrand <k...@gentoo.org> writes: >> inherited eclasses. having a whitelist in place and die if eclass is not >> updated to handle it solves it. >> >> Thoughts? comments? cookies? threats? > > Wouldn't a blacklist be more practical than a whitelist? > > root# cat /usr/portage/profiles/eclass.eapi.mask > > fooutils.eclass >=6 > > The problem seems infrequent enough that a blacklist is sufficient, like > all the *.mask files in /usr/portage/profiles. > > The whitelist places a large testing burden on eclass authors on each > EAPI bump, where 99% of the time there won't be any issue to fix.
A few things: 1. Your syntax assumes that EAPIs are ordered (I'll let the mathematicians go on about set theory). Nothing about PMS requires this, the next one could be "2B," or "Fred," or "😁." (Apologies on the last one if it doesn't come through, as I have no idea how UTF-8 safe email actually is.) I don't think it is likely, but I know somebody else will point it out if I don't. 2. I think that requiring eclasses to be reviewed before use on a new EAPI is a feature, and not a bug. It is a trivial update if it is fine, and depending on the nature of the eclass it might be trivial to determine if there will be a problem. If it isn't trivial to determine if there is a problem, it is probably even more important that it be reviewed. 3. The whole problem driving this is people using EAPIs with eclasses without realizing they fail in subtle ways. If they're unmaintained, this is even more likely to happen, and all the more reason to expose the problem. It is better to expose problems during design than at runtime. 4. EAPIs seem to come out about every other year right now. Is it really THAT hard to keep up with them? And eclasses which fall behind should probably be candidates for treecleaning anyway. -- Rich
