1 |
There's been a lot of noise on this list the past few days about GLEP |
2 |
55, but precious few solutions actually proposed. Changing the file |
3 |
extension would certainly be useful for some changes, but the success of |
4 |
EAPIs >0 which are already in the tree demonstrates that for many |
5 |
changes, altering the filename is unnecessary. Anything with a .ebuild |
6 |
extension will have to be parsable by bash according to some set of |
7 |
rules, for various reasons, so anything more exotic will require a file |
8 |
extension change. On the other hand, all current ebuilds *do* happen to |
9 |
parse just fine in bash, so there's no pressing need to change the |
10 |
extension for current packages. |
11 |
|
12 |
Instead of changing rules for existing ebuilds, then, why not formalize |
13 |
some guidelines for non-ebuild-compatible packages in the tree, separate |
14 |
from EAPIs? Allowing new package formats is the next logical |
15 |
generalization after considering new and incompatible ebuild formats, |
16 |
and it would probably be cleaner overall, while giving people the |
17 |
freedom to experiment with whatever wild ideas they have for packages. |
18 |
|
19 |
People are going to end up trying out new formats; just look at |
20 |
kdebuild-1. Rather than trying to put a lid on that sort of thing, and |
21 |
forcing every Gentoo package to be ebuild-compatible, there should be |
22 |
some kind of standard for how to treat new package formats, so that |
23 |
ground rules can be laid out. For instance, the whole thing will fall |
24 |
apart quickly if there aren't rules about dependencies between packages |
25 |
of different formats, and there are probably a lot of other issues that |
26 |
I haven't thought of - all the more reason for standards to be laid out. |
27 |
|
28 |
--Ravi |