1 |
Continuing in the series of issues raised during the previous package |
2 |
manager discussions, I'd like to continue by mentioning the tree |
3 |
format. At present, it isn't defined beyond "what the current portage |
4 |
supports", which is frankly a fairly silly way to do things. Following |
5 |
discussion in #gentoo-portage, I'd like to set out to change that. |
6 |
|
7 |
My current idea is to draw up a formal specification of what ebuilds |
8 |
are allowed to do, and what to assume about the environment in which |
9 |
they run, as well as defining the formats of everything under |
10 |
profiles/, metadata.xml files, and other auxiliary information in the |
11 |
tree. I would envision the first version of this document to more or |
12 |
less codify existing practise, perhaps excluding some dubious tricks |
13 |
that are known to break in some cases. Generally, it should be possible |
14 |
to make the tree conform to the first version of the specification by |
15 |
changes no more significant than currently have QA bugs filed for them. |
16 |
|
17 |
It seems fairly obvious that any effort of this kind could potentially |
18 |
have implications, albeit hopefully very minor, across more or less all |
19 |
aspects of the tree, and so I'd like to seek as wide a range of input |
20 |
as possible before going ahead with it. The QA and Portage teams, based |
21 |
on my enquiries in IRC, seem broadly in favour, and I would imagine |
22 |
that this could be very helpful to Gentoo/ALT as well, so I'd like |
23 |
opinions from others at this point. Would you support such an effort, |
24 |
whether passively or actively? Would you oppose it? If so, why? Final |
25 |
implementation of it would I assume require the Council's approval; |
26 |
while I won't ask at this stage for a formal discussion I'd appreciate |
27 |
the views of its members on whether such an initiative is likely to |
28 |
pass. |
29 |
|
30 |
Any input is gratefully received. |
31 |
-- |
32 |
gentoo-dev@g.o mailing list |