1 |
On Thu, 22 Jan 2009 09:28:31 -0800 |
2 |
Donnie Berkholz <dberkholz@g.o> wrote: |
3 |
> > Only if you're guaranteed bash 3.1 on boxes that do metadata |
4 |
> > generation. Which means it won't work for overlays. |
5 |
> |
6 |
> I'm not an expert on metadata generation, so please tell me if I'm |
7 |
> wrong here. Most if not all overlays don't ship pregenerated |
8 |
> metadata, which means users have to generate it locally. Without |
9 |
> doing so, they cannot install anything from that overlay that uses |
10 |
> bash features they lack. They can still install things from that |
11 |
> overlay that don't use the new bash features. |
12 |
> |
13 |
> Consequently, packages in overlays using new bash features won't work |
14 |
> till you upgrade your bash. They also won't be able to give you a |
15 |
> good error about how to fix it, because you can't guarantee that |
16 |
> you'll be able to parse the ebuild/eclass as far as the bash |
17 |
> dependency. |
18 |
|
19 |
It's the "won't work" bit that's the problem. Using bash-3.1 features |
20 |
with older bash won't generally give a fatal error. It'll just result |
21 |
in an easily missable message being shown to stderr, and the package |
22 |
carrying on with duff information. The failures can be extremely |
23 |
unobvious and can result in utterly h0rked packages being installed. |
24 |
|
25 |
> I guess a GLEP 42 news item would sort of work, but I really wish we |
26 |
> had tree dependencies. |
27 |
|
28 |
There're always profiles... But profiles have to be updated long before |
29 |
3.1 features are in use, to give people time to upgrade. |
30 |
|
31 |
> Another option would be to make overlay maintainers generate their |
32 |
> own metadata. |
33 |
|
34 |
Probably not viable. Metadata generation moves hosting an overlay from |
35 |
something you do with a VCS to a complicated procedure involving |
36 |
several interacting tools -- it's complicated enough that even the way |
37 |
it's done for gentoo-x86 doesn't always work properly... |
38 |
|
39 |
> We're getting into pretty weird territory here -- if you had slotted |
40 |
> bash versions, you could do bash-3.0 -n foo.ebuild, bash-3.1 -n |
41 |
> foo.ebuild, etc. |
42 |
|
43 |
That still wouldn't catch a lot of things... Unfortunately repoman |
44 |
can't replace developer knowledge. |
45 |
|
46 |
Short of persuading upstream to add a feature that makes bash able to |
47 |
die if it detects you using features added in a version newer than the |
48 |
one you tell it, there's not much that can be done beyond educating |
49 |
developers, restricting newer bash features to newer EAPIs and using |
50 |
GLEP 55 to handle the metadata generation problem. |
51 |
|
52 |
-- |
53 |
Ciaran McCreesh |