| 1 |
As package sets are mostly done now, I'm starting to think about |
| 2 |
something else. One of my pet peeves with portage is the "packages" |
| 3 |
file in profiles, for several reasons: |
| 4 |
1) it has two completely independent purposes |
| 5 |
2) it implements a redundant visibility filter as package.mask is also |
| 6 |
available in profiles |
| 7 |
3) the syntax for defining the "system" set plain sucks |
| 8 |
4) the name doesn't really say anything about the purpose |
| 9 |
|
| 10 |
Another issue that isn't directly related, but covered by the proposed |
| 11 |
solution below, is the so called "implicit system dependency" in |
| 12 |
ebuilds, which doesn't really exist. It only an assumption by people |
| 13 |
that the "system" set is satisfied before an ebuild is processed, so |
| 14 |
its contents don't have to be listed in *DEPEND. If a user breaks that |
| 15 |
assumption by not regulary ensuring that "system" is satisfied bugs can |
| 16 |
occur. Another issue is the informal exception when system items are |
| 17 |
allowed to/must be listed in *DEPEND, IMO that should be formalized. |
| 18 |
|
| 19 |
To solve both issues I propose the following system: |
| 20 |
Profiles can contain the files "system.depend" and "system.rdepend" |
| 21 |
whose combined contents make up the "system" target. If any of those |
| 22 |
two files exists the "packages" file is ignored. The syntax should |
| 23 |
either be the same as package.mask or, if desired, also allow complex |
| 24 |
atoms (use-conditionals, any-of constructs). |
| 25 |
The second part would be that portage implicitly adds the content of |
| 26 |
the files to the DEPEND or RDEPEND setting of each ebuild unless it |
| 27 |
contains RESTRICT=system-deps. Obviously this would have to be tied to |
| 28 |
a new EAPI version. (an undefined cornercase here is if a profile does |
| 29 |
not contain the new files, not sure how that should be handled) |
| 30 |
|
| 31 |
Benefits: |
| 32 |
- we get rid of all the issues outlined at the top |
| 33 |
- should make it easier long-term to setup a no-compile system that only |
| 34 |
installs binary packages due to separation of build- and runtime deps |
| 35 |
in "system" |
| 36 |
|
| 37 |
Problems: |
| 38 |
- obviously it has to be implemented first |
| 39 |
- no obvious solution for stacking rules (e.g. child uses system.*, but |
| 40 |
parent profile only has "packages") |
| 41 |
- some people might rely on the "packages" file |
| 42 |
|
| 43 |
So, comments? |
| 44 |
|
| 45 |
Marius |
| 46 |
|
| 47 |
-- |
| 48 |
Public Key at http://www.genone.de/info/gpg-key.pub |
| 49 |
|
| 50 |
In the beginning, there was nothing. And God said, 'Let there be |
| 51 |
Light.' And there was still nothing, but you could see a bit better. |
Archives