Hi Thomas,

Am Samstag, 4. März 2006 14:24 schrieb Thomas de Grenier de Latour:
> One point of view on this issues is that the ebuilds are wrong, because
> they are abusing the said USE flags, and they should rather die.  Imho,
> it makes sense, but if such a strict policy was applied to every
> ebuilds which atm are abusing flags this way, it would become really
> hard to put anything in the make.conf USE variable without breaking
> "emerge -uD world".

Just to throw in my 2 cents into this discussion: I'm all against die-ing
during the update process. However, i think that stopping before the update 
process would be the best solution at hand. I'd like to propose the addition 
of a dedicated USE conflict detection to ebuilds which need it.

This detection function (for example pkg_prepare()) must be executed for every 
package in the depgraph right after the depgraph has been built and has only 
the possibility to either mark the package as 'go' or 'no-go'. In case that 
any package has been marked as 'no-go', the whole process stops.

A possible implementation from the build side could look like this:

# the next two functions would be candidates for eutils.eclass
emutexuse() {
        eerror "The following USE flags are mutually exclusive:"
        eerror "[EMAIL PROTECTED]"
        eerror "Please choose only one of the above and disable the remaining"
        eerror "USE flags. For additional information about this problem, see"
        eerror "http://www.gentoo.org/<some place to store add. info about 
this>"
        echo
}

emissinguse() {
        eerror "In order to enable the ${2} USE flag you need also to enable"
        eerror "the ${1} USE flag. For additional information ...."
        echo
}

pkg_prepare() {
        local ret=0
        if use foo && use bar ; then
                emutexuse foo bar
                ret=1
        fi
        if use fnord2 && ! use fnord ; then
                emissinguse fnord fnord2
                ret=1
        fi

        return ${ret}
}

Comments?

Danny
-- 
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project

-- 
gentoo-dev@gentoo.org mailing list

Reply via email to