-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carsten Lohrke wrote:
> On Sonntag, 14. September 2008, Zac Medico wrote:
>> Well, I'm open to alternative suggestions. Please see the previous
>> email in which I've attempted to explain the reasoning for the given
>> approach [1]. It seems to me that this approach is well suited for
>> solving cases in which temporary simultaneous installation of
>> blocking packages is needed.
> 
> Thanks for pointing me to it, Zac. I do not pretend to be able to pull the 
> white bunny out of the black hat, presenting you the perfect alternative, 
> especially since you've thought about it a lot more than me. I just feel 
> uncomfortable, having ebuilds overwrite each others files. According to the 
> referenced data, it'll work around a number of issues. The time will show, If 
> real hard blocker issues remain a problem, I guess.

Since >=sys-apps/portage-2.1.5, heuristics have been used to allow
this behavior and there hasn't been a single report of it causing a
problem. Note that !atom will mean "_may_ be temporarily installed
simultaneously" rather than "_must_ be temporarily installed
simultaneously". Just because they _may_ be installed simultaneously
doesn't mean that it makes any sense to do so. It's only needed to
resolve a subset of cases (like bug 234886 [1]) and it's probably
best for the package manager to avoid doing it whenever possible.
When portage uses heuristics to trigger this behavior, as it does
when solving bug 234886 [1] automatically, it only uses this
approach when it finds that no viable alternative solution exists.

I might add that I consider these blocker extensions to have vital
importance since experience has show that manual resolution of
blockers is often difficult for users to accomplish on their own,
and even when they seek advice from others, they are often given
faulty advice. Most people just don't have the knowledge or
experience necessary to manually solve these types of problems
correctly. Even when the user does know how to manually solve the
problem correctly, it's an annoying task that's much better
automated. I consider lack of automatic resolution to be a severe
usability issue which upsets users and also increases supports costs
in the form of users complaining or seeking help in places like
{bugs,forums,lists}.gentoo.org.

>> Again, please see my previous email on this subject [1]. The reason
>> that I think we should change the meaning of the '!' symbol is that
>> the majority of existing EAPI 0 or 1 blockers appear to fit the new
>> meaning already. So, we'll only have to use the new !!atom syntax
>> for special cases in which temporary simultaneous installation of
>> blocking packages must be explicitly forbidden.
> 
> Just the majority or pretty much all and the others are easily to find out and 
> moved to EAPI 2, so the point I raised ceases to exist!?

It seems to me that the new !!atom syntax will only be needed in
relatively few cases, and it won't be hard for ebuild maintainers to
adjust to. I'm open to alternative suggestions though...

> I want to share another thought regarding this proposed addtion:
> 
> !! has the double meaning a) "unmerge the following ebuilds later" and 
> b) "overwriting files of the following ebuilds while merging changes makes 
> them owned by the freshly merged ebuild"
> 
> so we have one symbol denoting two different commands, which could find use 
> independently. Moreso, if we add more of these symbols to express something 
> different, our syntax may look almost like Lisp in the end:
> 
>  use? ( ! ( X ( Y ( || ( ( foo bar ) baz ) ) ) ) ) )
> 
> Looks ugly, doesnt it? 
> 
> How about using two symbols for !! and having the possibility to aggreagate 
> them, e.g.
> 
> use? ( !XY||: ( ( foo bar ) baz ) )
> 
> instead?!

Well, I suspect that you might be complicating things more than
necessary. I tend to think the syntax extensions that I've already
proposed are well suited to our needs.

[1] http://bugs.gentoo.org/show_bug.cgi?id=234886
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjNpYMACgkQ/ejvha5XGaOMjgCgqAYk6eeMyLUOS9qdC0lZU8GK
uVMAn0/cf9xJPnAppok+AvkQ/99MGQhQ
=r1D/
-----END PGP SIGNATURE-----