| 1 |
Hi gang. |
| 2 |
|
| 3 |
I have discussed the need for this with drobbins last week. Sorry it took |
| 4 |
so long before my suggestion materialized. |
| 5 |
|
| 6 |
Woodchip: Warning, long and complicated mail (but this is justified by |
| 7 |
sticking to one topic through the entire mail, I should hope) ;p |
| 8 |
|
| 9 |
|
| 10 |
|
| 11 |
We have sometimes discussed the need for a more precise syntax (and adhering |
| 12 |
implementation) for specifying dependencies between packages. |
| 13 |
|
| 14 |
Why do we want a more powerful dependency system ? |
| 15 |
|
| 16 |
- If for no other reason, it's because the current syntax cannot gracefully |
| 17 |
handle ! (not) |
| 18 |
- We really want to be able to have a set-theoretic-based syntax, since that |
| 19 |
is what is employed (logically) inside Portage. |
| 20 |
|
| 21 |
Since the syntax is so closely tied to the functionality it represents, I |
| 22 |
will spare you the linguistic babble about semantics and rules, and rather |
| 23 |
let the syntax speak for itself. |
| 24 |
|
| 25 |
|
| 26 |
New syntax for complex dependencies: |
| 27 |
|
| 28 |
dev-libs/glib[ >=1.2 ] |
| 29 |
|
| 30 |
- This can of course also be written a tad simpler as |
| 31 |
|
| 32 |
>=dev-libs/glib-1.2 |
| 33 |
|
| 34 |
|
| 35 |
dev-libs/glib[ >=1.2 <=1.2.14 ] |
| 36 |
|
| 37 |
- This defines the interval from 1.2.0 to 1.2.14, inclusive. |
| 38 |
|
| 39 |
dev-libs/glib[ >1.2 <1.2.14 =1.2.18] |
| 40 |
|
| 41 |
- This defines the interval from 1.2.1 to 1.2.13, inclusive (yes, |
| 42 |
read twice if you disagree), plus 1.2.18 |
| 43 |
|
| 44 |
dev-libs/glib[1.2*] |
| 45 |
|
| 46 |
- This defines any 1.2 version, and is equivalent to |
| 47 |
|
| 48 |
dev-libs/glib-1.2* |
| 49 |
|
| 50 |
|
| 51 |
dev-libs/glib[1.2* !1.2.12* 1.2.12.3] |
| 52 |
|
| 53 |
- All 1.2 versions are okay, _except_ any 1.2.12 versions , |
| 54 |
but 1.2.12.3 is okay again. (Call this set A). |
| 55 |
|
| 56 |
dev-libs/glib[ ((1.2* !1.2.12* 1.2.12.3) | 1.3*) & >=1.4.12 ] |
| 57 |
|
| 58 |
- Any of the versions in set A are okay, or any 1.3 version. In addition, |
| 59 |
we also have to have 1.4.12 or newer installed. |
| 60 |
|
| 61 |
This is where the new system allows us to package things that are really |
| 62 |
weird and require multiple versions of various things, without resorting |
| 63 |
to calling the base package libxml2 or ssh2 or qt3, or whatever. |
| 64 |
|
| 65 |
The same syntactical constructs can also be applied at inter-package |
| 66 |
level: |
| 67 |
|
| 68 |
DEPEND="[ dev-libs/foo[1.2* !1.2.12*] | >=dev-libs/bar-1.3 ] |
| 69 |
=dev-libs/baz-1.0" |
| 70 |
|
| 71 |
DEPEND="foo? ([ dev-libs/foo[1.2* !1.2.12*] & |
| 72 |
>=dev-libs/baz-1.0 | |
| 73 |
=dev-libs/baar-1.0] )" |
| 74 |
|
| 75 |
|
| 76 |
In general, [] enclose the new syntactical constructs, and thus act as |
| 77 |
an 'escape mechanism' from the old syntax. |
| 78 |
|
| 79 |
One thing about the '|' (or) construct: foo | bar is equivalent to: |
| 80 |
if not foo, then bar, it does NOT mean foo & !bar. |
| 81 |
|
| 82 |
|
| 83 |
The main problem of exporting such as powerful/possibly complex mechanism |
| 84 |
as this, is that ebuilds can become unmaintainable. I really do not think |
| 85 |
that will be a problem, since for the majority of ebuilds, the "simplified" |
| 86 |
(ie, old) syntax is more than enough. |
| 87 |
|
| 88 |
Only for fairly complex dependendency cases will the (full) power of the |
| 89 |
new syntax be applied, and that will probably always be done by the hardcore |
| 90 |
Gentoo packagers anyway. |
| 91 |
|
| 92 |
I have elected not to comment on some of the more subtle points at various |
| 93 |
points above. If anybody wants to get really dirty, I suggest we do it on |
| 94 |
IRC. |
| 95 |
|
| 96 |
Comments are required! |
| 97 |
|
| 98 |
|
| 99 |
|
| 100 |
Kind regards, |
| 101 |
|
| 102 |
Karl T |
Archives