| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Carsten Lohrke wrote: |
| 5 |
> On Sonntag, 14. September 2008, Zac Medico wrote: |
| 6 |
>> Well, I'm open to alternative suggestions. Please see the previous |
| 7 |
>> email in which I've attempted to explain the reasoning for the given |
| 8 |
>> approach [1]. It seems to me that this approach is well suited for |
| 9 |
>> solving cases in which temporary simultaneous installation of |
| 10 |
>> blocking packages is needed. |
| 11 |
> |
| 12 |
> Thanks for pointing me to it, Zac. I do not pretend to be able to pull the |
| 13 |
> white bunny out of the black hat, presenting you the perfect alternative, |
| 14 |
> especially since you've thought about it a lot more than me. I just feel |
| 15 |
> uncomfortable, having ebuilds overwrite each others files. According to the |
| 16 |
> referenced data, it'll work around a number of issues. The time will show, If |
| 17 |
> real hard blocker issues remain a problem, I guess. |
| 18 |
|
| 19 |
Since >=sys-apps/portage-2.1.5, heuristics have been used to allow |
| 20 |
this behavior and there hasn't been a single report of it causing a |
| 21 |
problem. Note that !atom will mean "_may_ be temporarily installed |
| 22 |
simultaneously" rather than "_must_ be temporarily installed |
| 23 |
simultaneously". Just because they _may_ be installed simultaneously |
| 24 |
doesn't mean that it makes any sense to do so. It's only needed to |
| 25 |
resolve a subset of cases (like bug 234886 [1]) and it's probably |
| 26 |
best for the package manager to avoid doing it whenever possible. |
| 27 |
When portage uses heuristics to trigger this behavior, as it does |
| 28 |
when solving bug 234886 [1] automatically, it only uses this |
| 29 |
approach when it finds that no viable alternative solution exists. |
| 30 |
|
| 31 |
I might add that I consider these blocker extensions to have vital |
| 32 |
importance since experience has show that manual resolution of |
| 33 |
blockers is often difficult for users to accomplish on their own, |
| 34 |
and even when they seek advice from others, they are often given |
| 35 |
faulty advice. Most people just don't have the knowledge or |
| 36 |
experience necessary to manually solve these types of problems |
| 37 |
correctly. Even when the user does know how to manually solve the |
| 38 |
problem correctly, it's an annoying task that's much better |
| 39 |
automated. I consider lack of automatic resolution to be a severe |
| 40 |
usability issue which upsets users and also increases supports costs |
| 41 |
in the form of users complaining or seeking help in places like |
| 42 |
{bugs,forums,lists}.gentoo.org. |
| 43 |
|
| 44 |
>> Again, please see my previous email on this subject [1]. The reason |
| 45 |
>> that I think we should change the meaning of the '!' symbol is that |
| 46 |
>> the majority of existing EAPI 0 or 1 blockers appear to fit the new |
| 47 |
>> meaning already. So, we'll only have to use the new !!atom syntax |
| 48 |
>> for special cases in which temporary simultaneous installation of |
| 49 |
>> blocking packages must be explicitly forbidden. |
| 50 |
> |
| 51 |
> Just the majority or pretty much all and the others are easily to find out and |
| 52 |
> moved to EAPI 2, so the point I raised ceases to exist!? |
| 53 |
|
| 54 |
It seems to me that the new !!atom syntax will only be needed in |
| 55 |
relatively few cases, and it won't be hard for ebuild maintainers to |
| 56 |
adjust to. I'm open to alternative suggestions though... |
| 57 |
|
| 58 |
> I want to share another thought regarding this proposed addtion: |
| 59 |
> |
| 60 |
> !! has the double meaning a) "unmerge the following ebuilds later" and |
| 61 |
> b) "overwriting files of the following ebuilds while merging changes makes |
| 62 |
> them owned by the freshly merged ebuild" |
| 63 |
> |
| 64 |
> so we have one symbol denoting two different commands, which could find use |
| 65 |
> independently. Moreso, if we add more of these symbols to express something |
| 66 |
> different, our syntax may look almost like Lisp in the end: |
| 67 |
> |
| 68 |
> use? ( ! ( X ( Y ( || ( ( foo bar ) baz ) ) ) ) ) ) |
| 69 |
> |
| 70 |
> Looks ugly, doesnt it? |
| 71 |
> |
| 72 |
> How about using two symbols for !! and having the possibility to aggreagate |
| 73 |
> them, e.g. |
| 74 |
> |
| 75 |
> use? ( !XY||: ( ( foo bar ) baz ) ) |
| 76 |
> |
| 77 |
> instead?! |
| 78 |
|
| 79 |
Well, I suspect that you might be complicating things more than |
| 80 |
necessary. I tend to think the syntax extensions that I've already |
| 81 |
proposed are well suited to our needs. |
| 82 |
|
| 83 |
[1] http://bugs.gentoo.org/show_bug.cgi?id=234886 |
| 84 |
- -- |
| 85 |
Thanks, |
| 86 |
Zac |
| 87 |
-----BEGIN PGP SIGNATURE----- |
| 88 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 89 |
|
| 90 |
iEYEARECAAYFAkjNpYMACgkQ/ejvha5XGaOMjgCgqAYk6eeMyLUOS9qdC0lZU8GK |
| 91 |
uVMAn0/cf9xJPnAppok+AvkQ/99MGQhQ |
| 92 |
=r1D/ |
| 93 |
-----END PGP SIGNATURE----- |
Archives