Hello, On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote:
> With eapis 1 and 2 we introduced nice features but also a couple of > new > problems. One of them are the use dependencies when the package you > depend on doesn't have the use flag anymore (see [1] for an example). > > So I think it's time for a short eapi bump with some distinct > improvements: > > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ > > > Please discuss. Sorry for getting my points of discussion on the details to the list so late. I have covered some of my concerns on the items in meetings and otherwise on IRC, but now I'll try to get to them in further detail and better wording to the mailing list. I'm going to go item-by-item here for the things I don't expect much replies to, and then starting separate threads for those that I do. pkg_pretend =========== No objections. Gives an intermediate step for handling USE flag combination incompatibilities at pretend stage (to not find it failed in the morning), yet has uses outside that as well. So, once there is a way to express those kind of USE flag dependencies outside of pkg_pretend in a better way in a future EAPI, pkg_pretend will still be useful for other (less common) cases and can provide a description of the problem to the user. Use based deps with non-existing USE flags ========================================== No objections. Implements the missing bit of "built_with_use --missing" Main driving force behind EAPI-3. default src_install =================== No considerable input yet, catching up with the latest thread about src_install bikeshedding doinclude ========= Unnecessary. Might be interesting for automatic executable permission removing, but upstream build systems should be fixed instead for such a big and rare error. ban dosed ========= I don't exactly see a reason for the banning yet, but no objections due to general agreement on it and having no technical objections doins support for symlinks ========================== Lacking information. Need to see if the PMS draft has anything about it. The bug and summaries just talk about the support, but no details. Would it be an argument to doins? unpack failing on unknown types =============================== Uncertain about it's worthiness. Might rather have the opposite with a --strict argument kind of deal. No official objection from me. docompress ========== Need some more time to digest through it in relation to PORTAGE_COMPRESS, prepalldocs and co. Will try to follow-up before meeting. properties must be cached properly ================================== No opinion, up to the package manager developers. Don't see offhand why it should be an EAPI item at all. Feels like an implementation detail. DEFINED_PHASES must be supported (and cached properly) ====================================================== No opinion, up to the package manager developers more or less. Not sure why this needs to be an EAPI item. Hard to see a use case for the variable being available for ebuild usage for it to be necessary to be an EAPI item. By my understanding it is (also?) a required implementation detail to handle pkg_pretend sanely and with minimal time hit. Limit values in $USE to ones in $IUSE: ====================================== Seems more of a QA test, but forcing it can make it be caught at start. Don't see why it must be an EAPI item. Just vet the tree of (future?) repoman warnings about it and make it happen for all EAPIs. Impact on overlays is minimal because it is a QA error to not define them and they get what they asked for. Not strongly opposed to it being in the EAPI. --disable-dependency-tracking: ============================== possible breakage of (custom) configure scripts that don't accept unknown arguments. Would be nice to pass that for most packages, but doing it always with econf seems slightly inappropriate, given the above. Don't think this is an item for fast-tracked EAPI-3. utility commands should die by default ====================================== Would like to see a list of those utility commands that would be made to die by default. ban || ( foo? ( . ) . ) ======================= It is not the business of an EAPI to start disallowing *DEPEND string constructs. There is no useful alternative provided yet to my knowledge and this is really a QA issue, not an EAPI issue. Not convinced on the sub-optimal use case being the only one, either. Strongly objecting on the grounds that it is not something that should be an EAPI issue. unpack has to handle more types =============================== Would be nice to get a QA warning when unpacking .lzma, .xz, etc that need a build depend for the unpacker and don't have it yet. Then sounds fine. In separate threads: * Slot operator support * dohard being deprecated Did I miss anything? I'm not even sure anymore where to find a list of items that is current for what's on the table for EAPI-3 right now... -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
