Mailing List Archive

On Fri, 3 Mar 2006 23:31:49 +0100
Jakub Moc <jakub@gentoo.org> wrote:

> Yeah, that's a wonderful message. Let users choose, they are not
> idiots and such policy does more harm than good. Period.

You're completely missing the point here. The user has a choice, but if
his set of choices doesn't make sense for whatever reason, you have
to decide on some sane way to configure the package. How you come to
that decision is irrelevant, hence the 'flip a coin'.
--
gentoo-dev@gentoo.org mailing list

3.3.2006, 23:32:36, Grant Goodyear wrote:

> Jakub Moc wrote:
>> Erm, how exactly will you find out that you need to recompile that package
>> after such extensive build? You'll spend a couple of hours debugging when
>> your server app stops working? Yay! :P

> I had assumed that in such a case the ebuild would output a
> scary-looking ewarn that notified the user of such a problem.

The whole argument here is that bailing out with conflicting use flags
breaks some extensive compiles. So you suppose users will be sitting in
front of their monitor and stare on the screen waiting for a scary warning?
No, they won't. And even if they were, how exactly is that warning better
than bailing out and asking them to change the use flags?

The only thing that can happen here is that users will get unexpected
results and will be debugging their broken apps once that extensive compile
that must not be interrupted under any circumstances is finished.

>> Oh please, stop making up artificial policies doing no good to users just to
>> hack around lacking features in portage.

> Was I so impolite that you felt the need to be rude in turn? If so, I
> certainly apologize, as it was not my intention.

No, sorry. That comment was aimed generally at whomever is making up such
policies. I'm really getting tired of this debate. Lets drop the damned
paragraph that has been added recently and lets do some more important job.
This simply cannot be fixed now in a reasonable way that would improve user
experience, so why don't we focus on something that is doable?

> I don't believe that I made up this policy, although it's been around as
> an unofficial policy for so long that I couldn't really say one way or
> the other. In any event, I certainly agree that fixing portage would be
> preferable to policies that work around portage's warts. On the other
> hand, until those warts get fixed it seems useful to have a set of "best
> practices" in the meantime. I'm arguing that sudden, difficult to
> predict package build breakages are a bigger sin than having a package
> build deterministic functionality that may be unexpected by the user.
> You (I think) believe the opposite. Fair enough.

Well, selecting features randomly is not what I believe could be a "best
practice".

--

jakub

Stuart Herbert wrote:
>>>It prevents emerge from crashing out in the middle of what could be a
>>>quite extensive build. Personally, I would rather rebuild one package
>>>to get desired functionality _after_ the emerge completes than have to
>>>fix the flags for that one package to be able to build everything else.
>
>
> This is why Ciaran and I opened a bug for the Portage team to get this
> handled up-front. Alas, I can't find the bug any more to reference it
> here :(

bug 75936

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Member
--
gentoo-dev@gentoo.org mailing list

Hi Grant,

On 3/3/06, Grant Goodyear <g2boojum@gentoo.org> wrote:
> Yep. Having a USE flag enabled turns out not to be a guarantee. That
> said, package builds do become deterministic, so (for example) if one
> needs to know if msmtp was built with openssl or gnutls it is easy
> enough to pull the logic from the msmtp ebuild.

If a build process has errors, it should stop. That's still
deterministic. I'd respectfully argue that it's far more
deterministic than having each single package implement separate
policy for handling conflicting USE flags.

Policy belongs with the user, not in Portage. It's exactly the same
as the kernel pushing policy into userspace.

I believe that it's bad engineering to force (using your example)
packages that depend on msmtp to have to copy the logic from the msmtp
ebuild to understand how to correctly depend on that package. It
violates the principle of Don't Repeat Yourself.

If we're going to do this, then at least we should be implementing a
consistent standard across all ebuilds. F.ex, when SSL and TLS
conflict, we should have a standard saying that all ebuilds will
consistenly favour one over the other. That's much more deterministic
than having some ebuilds prefer SSL, and others prefer TLS (for
example).

> I'm sure that there is
> a more elegant solution, but I'm not convinced that having the user
> randomly throw USE flags at a package until some combination works is
> necessarily it. I could be wrong, however. *Shrug*

Why would the user be randomly throwing USE flags at a package? With
the PHP ebuilds and the confutils eclass, we've already proved that
you can tell the user exactly why the ebuild has bailed, and what they
can do to fix it.

> With an apology for singling you out (when yours is certainly not the
> only, or even the most appropriate, example), that sort of emotional
> response is how these threads begin to degenerate. There appears to be
> an implicit assumption there that your view is clearly correct, and any
> other is embarrassingly silly. Instead, I suggest that perhaps people
> on both (all?) sides of the issue are rational, intelligent people who
> simply differ on what happens to be the greatest evil.

I accept the point, but, well, I *am* embarrassed. I guess I'm just
willing to admit it when others would rather not be open and honest
about how this makes them feel. I think it's fair to raise that as
part of the debate. I don't think we talk enough about how we feel
about what's happening to Gentoo these days. I think it's reasonable
that issues like this are delt with both on an emotional intelligence
level as well as an intellectual one.

> I would argue that the user tends to get unexpected results in either
> case, it's just a matter of whether the build crashes, or the resulting
> package is somewhat unexpected. Given that fact, I'm arguing that
> having a potentially-lengthy emerge crash out is the bigger evil.

I can understand how that matters to first-time installs, or users
running old hardware. My environment and concern are servers, where
dual-Xeon or dual-Opterons are the norm. The time it takes to install
a package is trivial against the time it takes to diagnose why it
isn't working the way you would expect.

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list

On Fri, 3 Mar 2006 23:14:41 +0000 "Stuart Herbert"
<stuart.herbert@gmail.com> wrote:
| If we're going to do this, then at least we should be implementing a
| consistent standard across all ebuilds. F.ex, when SSL and TLS
| conflict, we should have a standard saying that all ebuilds will
| consistenly favour one over the other. That's much more deterministic
| than having some ebuilds prefer SSL, and others prefer TLS (for
| example).

And what of gtk vs qt, where for many packages one is clearly the
preferred choice, but which one this is varies between packages? Do
*you* know which GUI is the best option for gvim and why?

Heck, it's hard enough figuring out a usable set of USE flags for PHP.
If we started dieing for the three zillion or so mutually independent
GUI options in gvim7 users would never actually be able to figure out
how to install the thing...

--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

> The whole argument here is that bailing out with conflicting use flags
> breaks some extensive compiles. So you suppose users will be sitting in
> front of their monitor and stare on the screen waiting for a scary warning?
> No, they won't. And even if they were, how exactly is that warning better

No they won't, but elog in portage-2.1 will gladly send them a message
via whatever configuration they have about the warning that the ebuild
produced.

-Alec Warner
--
gentoo-dev@gentoo.org mailing list

On Friday 03 March 2006 18:14, Stuart Herbert wrote:
> If we're going to do this, then at least we should be implementing a
> consistent standard across all ebuilds. F.ex, when SSL and TLS
> conflict, we should have a standard saying that all ebuilds will
> consistenly favour one over the other. That's much more deterministic
> than having some ebuilds prefer SSL, and others prefer TLS (for
> example).

bad idea ... choosing a default is a per-package issue. say we take this path
and we declare that if a package supports both tls and ssl, you must utilize
tls over ssl regardless. then you come to a package has really shitty tls
support but it has wonderful ssl support. you're saying that defaulting to
tls is a better idea than ssl ? a global decision like this just wont cut
it.
-mike
--
gentoo-dev@gentoo.org mailing list

Alec Warner wrote:
>> The whole argument here is that bailing out with conflicting use flags
>> breaks some extensive compiles. So you suppose users will be sitting in
>> front of their monitor and stare on the screen waiting for a scary
>> warning?
>> No, they won't. And even if they were, how exactly is that warning
>> better
>
> No they won't, but elog in portage-2.1 will gladly send them a message
> via whatever configuration they have about the warning that the ebuild
> produced.
>
> -Alec Warner
Greetings dear Gentoo developers.

I would like to give you my humble point of view on this subject as a
simple gentoo user.

A few days after an emerge that took 7 hours to complete I used the
portlog-info script to extract the warnings from the portage log (I'm
using portage 2.0.54 on that computer so no elog there). While reading
these warnings I came to this one:

=== 2006-02-12 01:01 =========== php-4.4.0-r4 ===
= /var/log/portage/2729-php-4.4.0-r4.log (4.0K) =
...
* If you have both freetds and mssql in your USE flags, parts of PHP
* may not behave correctly, or may give strange warnings. You have
* been warned! It's recommended that you pick ONE of them. For sybase
* support, chose 'freetds'. For mssql support choose 'mssql'.
* If you have additional third party PHP extensions (such as
* dev-php/eaccelerator) you may need to recompile them now.
...

So now, even if I have no knowledge about PHP, I know that if something
is going wrong with it I will have to check these use flags. And if I
was not so lazy I would have a look at them right now to be sure
nothing bad will happen.

I feel more comfortable with this behavior than with a long emerge that
would have stopped in the middle because of potentially conflicting use
flags.

(sorry for my bad English and thank you all for your good work. I just
love Gentoo)

Fabrice Bellamy







___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
--
gentoo-dev@gentoo.org mailing list

Mike Frysinger wrote:
> On Wednesday 01 March 2006 21:53, Mark Loeser wrote:
>> Here is my updated version after some feedback from people:
>>
>> * In case of emergency, or if package maintainers refuse to cooperate,
>> the QA team may take action themselves to fix the problem.
>> * The QA team may also offer to fix obvious typos and similar minor
>> issues, and silence from the package maintainers can be taken as
>> agreement in such situations.
>> * In the event that a developer still insists that a package does not
>> break QA standards, an appeal can be made at the next council meeting.
>> The package should be dealt with per QA's request until such a time that a
>> decision is made by the council.
>
> one thing i dont think we give enough emphasis to is that our tools arent
> perfect ... sometimes we utilize QA violations to work around portage
> limitations ... if you want to see some really sweet hacks, review any of the
> toolchain related ebuilds and the hacks ive had to add to get cross-compiling
> to the usuable state that it is today. a handful of them would fall under
> the 'severe' category i'm sure. and if we want to use the lovely php
> example, personally i think that given portage's current limitations, the
> latest dev-lang/php ebuild is probably one of the best solutions that could
> have been developed, thanks Stuart for all the flak you've had to take over
> this. also, many games ebuilds break the 'non-interactive' policy by
> displaying licensing and making the user hit "Y" because portage lacks checks
> where the user explicitly states what licenses they accept.
> -mike


I installed dev-lang/php on a server in my house to test
torrents.gentoo.org and ramereth also installed it on the torrents.g.o
server. I have to say that it was a painless and normal operation with
no errors. Thanks for the hard work on this ebuild, it's appreciated.

On Fri, 3 Mar 2006 22:44:22 +0000,
"Stuart Herbert" <stuart.herbert@gmail.com> wrote:

> Unless a user looks inside the ebuild, they're not going to
> understand why the USE flags they've selected has resulted in a
> package that doesn't actually have those features.
...
> This is going to *create* more support, not reduce it.

The problem here, from a user point of view, is the USE flag usage not
matching its description (that's what makes "unexpected" the ebuild
behavior). For instance, description says "foo - Enable libfoo",
whereas actually the ebuild will only use libfoo if some other "bar" is
unset.

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 take the default flags from x86 profile for instance: both "motif"
("Adds motif support") and "gtk" ("Adds support for x11-libs/gtk+") are
enabled, whereas the logic in several packages supporting both is to
build the GTK interface when "gtk" is on, and to build a Motif one
otherwise, if "motif" is on. Do you think such ebuilds should rather
die at compile time, asking the user to make an unconflicting choice?
I don't. My package.use is already ~200 lines long for various other
reasons, and i really don't want to double its size again just to
make my "emerge -uD world" successfully terminating.

Now, an alternative point of view is that what is wrong is rather the
USE flag descriptions. That's exactly what the "package specific USE
flag descriptions" proposal, which popups on this list from time to
time, is about (sorry, no URL because GMane seems down, but i can post
some later if you're interested).
The idea (or at least my pov on this idea, but others had different
views iirc) is that emerge could display some package-specific flags
descriptions in such cases. Using the emerge patch from bug #84884,
and with a "use.local.desc" entry for "app-editors/gvim:motif", the
user would be warned about what the "motif" flag actualy does (or does
not) on this package:

---------------
% emerge -pv --use-desc-special gvim
...
[ebuild R ] app-editors/gvim-6.4 USE="-acl bash-completion cscope
gnome gpm gtk motif nls -perl python ruby" 0kB
...
The following USE flags have package-specific descriptions:
app-editors/gvim
motif - Include support for the Motif GUI, but if "gtk" or "gnome"
flags are turned on too, in which case they are prefered.
---------------

This way, nothing unexpected for users, and no complain for devs.

--
TGL.
--
gentoo-dev@gentoo.org mailing list

On Friday 03 March 2006 23:32, Grant Goodyear wrote:
> Stuart Herbert wrote:
> > I agree. Adopting a policy like this is a low quality solution for
> > servers. I've no opinion on how this affects desktops, but packages
> > for servers need to be precise. A policy that says "if two USE
> > flags deliver the same benefits, but conflict, pick one" is fine. But
> > saying "flip a coin" ... how on earth is that "quality"?
>
> See my previous post.
>
> > And how the heck is it going to work w/ USE-based defaults? This
> > creates a situation where package (b) cannot trust that a feature is
> > enabled in package (a), even if package (a) was built with the
> > required USE flags.
>
> Yep. Having a USE flag enabled turns out not to be a guarantee. That
> said, package builds do become deterministic, so (for example) if one
> needs to know if msmtp was built with openssl or gnutls it is easy
> enough to pull the logic from the msmtp ebuild. I'm sure that there is
> a more elegant solution, but I'm not convinced that having the user
> randomly throw USE flags at a package until some combination works is
> necessarily it. I could be wrong, however. *Shrug*

You mean the logic should be replicated between msmtp and all packages that
need to know how it was built. I see this as a bigger source of bugs (msmtp
changes, some of the dependants forget to change too) than verifying at setup
time that the package has sane use flags. I'd prefer that a stage were
introduced that runs at pretend time exactly for these things. I would say it
is a bug if a useflag was specified for a package, including dependencies,
and the package does not actually depend on it because the useflag was not
actually applied. But even if the dependencies are proper, it is a bug from a
HCI point of view. A package should deliver what it promisses. If it can't it
should fail, not silently ignore the request.

>
> > Until Portage supports resolving conflicting USE flags when the
> > deptree is built, the practical thing to do is for ebuilds w/
> > conflicting USE flags to bail.
>
> I, quite respectfully, disagree.

As explained above, when an ebuild can not deliver, it should fail, not
silently downgrade its features. Especially when other packages may depend on
those features being present.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Saturday 04 March 2006 00:29, Ciaran McCreesh wrote:
> On Fri, 3 Mar 2006 23:14:41 +0000 "Stuart Herbert"
>
> <stuart.herbert@gmail.com> wrote:
> | If we're going to do this, then at least we should be implementing a
> | consistent standard across all ebuilds. F.ex, when SSL and TLS
> | conflict, we should have a standard saying that all ebuilds will
> | consistenly favour one over the other. That's much more deterministic
> | than having some ebuilds prefer SSL, and others prefer TLS (for
> | example).
>
> And what of gtk vs qt, where for many packages one is clearly the
> preferred choice, but which one this is varies between packages? Do
> *you* know which GUI is the best option for gvim and why?

Than say in the policy "For the choice TLS vs SSL choose SSL. For the choice
GTK vs QT choose the upstream preferred; if there is none, choose QT" (Don't
pin me on the choices in this example)

> Heck, it's hard enough figuring out a usable set of USE flags for PHP.
> If we started dieing for the three zillion or so mutually independent
> GUI options in gvim7 users would never actually be able to figure out
> how to install the thing...

The problem is that these flags are dependent. Bailing out on independent
useflags is not needed.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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 "${@}"
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 <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project

--
gentoo-dev@gentoo.org mailing list

4.3.2006, 2:57:51, Alec Warner wrote:

>> The whole argument here is that bailing out with conflicting use flags
>> breaks some extensive compiles. So you suppose users will be sitting in
>> front of their monitor and stare on the screen waiting for a scary warning?
>> No, they won't. And even if they were, how exactly is that warning better

> No they won't, but elog in portage-2.1 will gladly send them a message
> via whatever configuration they have about the warning that the ebuild
> produced.

Along with messages from another 127 or so ebuilds from that "extensive"
compile (let alone the fact that portage 2.1 isn't stable).

I'm done here, this isn't going anywhere. Feel free to join us on
#gentoo-php to provide support for the resulting miscompiled code and
related issues...

Ktnxbye.

--

jakub

Hi Ciaran,

On 3/3/06, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> And what of gtk vs qt, where for many packages one is clearly the
> preferred choice, but which one this is varies between packages? Do
> *you* know which GUI is the best option for gvim and why?

No, I don't. But that doesn't mean the user shouldn't make the
choice. Even if it is the wrong one from your point of view with your
additional knowledge.

We're a metadistribution, not a distribution. We're supposed to be
all about allowing the user to tailor each and every package to
his/her exact specification.

I think the policy of 'never die' would be understandable for a
distribution, but I don't feel it's appropriate for a
metadistribution.

> Heck, it's hard enough figuring out a usable set of USE flags for PHP.

How so? We've worked very hard to ensure that's not the case. What
have we missed?

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list

Hi Mike,

On 3/4/06, Mike Frysinger <vapier@gentoo.org> wrote:
> bad idea ...

Yes it is a bad idea; policy belongs with users. It shouldn't be
hardcoded into ebuilds, whether across the whole tree or per package.

But ... I realise I'm flogging a dead horse here.

We'll come up with a new revision of the PHP packages which builds
*something* no matter how broken the combination of USE flags are.
We'll test it first in our overlay, and then when we're happy we'll
add them to the tree for testing and eventual stabilisation.

We'll also provide a replacement for 'built_with_use', which works
with what the package was actually compiled with, rather than what USE
flags the user originally specified. This will be needed for all the
web-based apps that are written in PHP. That might take a bit longer,
and might have to follow in a later revision.

As already pointed out, all this will have to be revisited when
Portage supports USE-based deps.

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list

On Saturday 04 March 2006 23:45, Danny van Dyk wrote:
> 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 sounds the most reasonable. I can't see portage ever supporting "the 'foo'
and 'bar' flags can be used together except when 'baz' is also used" type flag
interdepency complexity. As Mike pointed out, check_license also needs to be
accounted for as well as possible others.

--
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Hi Danny,

On 3/4/06, Danny van Dyk <kugelfang@gentoo.org> wrote:
> 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 is the sort of thing we're asking for in bug #75936.

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list

Danny van Dyk <kugelfang@gentoo.org> said:
> 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.

I'd rather see the ebuild marked with some flag to show there are
conflicting use flags that have been resolved, and by adding "--verbose"
or some other flag, you can see what flags are overridden so the user
knows exactly what is going on, and can decide if they like the defaults
the ebuild developer has chosen. I think we should give users the
choice/information to make an informed decision, but I don't think we
should shove a failure into their lap when we can make choices for them
which we believe to be sane.

I'd like less errors/dies during the build/deptree phase and more
warnings/information to be presented so the user could look at it and
make changes, or just accept what we have done for them.

--
Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86)
email - halcy0n AT gentoo DOT org
mark AT halcy0n DOT com
web - http://dev.gentoo.org/~halcy0n/
http://www.halcy0n.com

On Saturday 04 March 2006 15:45, Danny van Dyk wrote:
> 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.
>
Perhaps it would be possible to tell portage to have a
"build-what-you-can" mode, where it tries to build as much as possible
after a compilation failure. At the end it then can report on the
packages that were not compiled.

> 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.

And this indeed.

>
> 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 "${@}"
> 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
> }
>

Add some reference to the package for which they are mutually exclusive.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

Paul de Vrieze wrote:
> On Saturday 04 March 2006 15:45, Danny van Dyk wrote:
>
>>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.
>>
>
> Perhaps it would be possible to tell portage to have a
> "build-what-you-can" mode, where it tries to build as much as possible
> after a compilation failure. At the end it then can report on the
> packages that were not compiled.
>

We've had a bug for this for years, no one has implemented it.

Most of the Portage developers would prefer USE-deps to anything else,
as this is what that is really trying to cover. The only alternative
I'm willing to support at this time is moving the death ( per
Kugelfang's suggestion ) to right after depgraph building. Thus a user
will find out right away that their USE flags conflict and need to be
changed. Even with USE deps, there cases that just aren't resolvable,
they are "unsolveable" and I think coming up with some sort of structure
to inform the user of this is a good idea.

However we have talked about this and the DEPEND syntax doesn't seem to
cut it for showing USE conflicts and dependencies. Certainly right now
the resolver has no metadata whatsoever to work with, so it can't even
tell if a specific set of USE flags conflict or not, if we provide it
with that information it can at least die during depgraph creation
stating what the problem is with the depgraph ( getting closer to having
actaul buildplans... ).

-Alec Warner
--
gentoo-dev@gentoo.org mailing list