Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

On Thu, 22 Jan 2009 09:28:31 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > Only if you're guaranteed bash 3.1 on boxes that do metadata
> > generation. Which means it won't work for overlays.
> 
> I'm not an expert on metadata generation, so please tell me if I'm
> wrong here. Most if not all overlays don't ship pregenerated
> metadata, which means users have to generate it locally. Without
> doing so, they cannot install anything from that overlay that uses
> bash features they lack. They can still install things from that
> overlay that don't use the new bash features.
> 
> Consequently, packages in overlays using new bash features won't work 
> till you upgrade your bash. They also won't be able to give you a
> good error about how to fix it, because you can't guarantee that
> you'll be able to parse the ebuild/eclass as far as the bash
> dependency.

It's the "won't work" bit that's the problem. Using bash-3.1 features
with older bash won't generally give a fatal error. It'll just result
in an easily missable message being shown to stderr, and the package
carrying on with duff information. The failures can be extremely
unobvious and can result in utterly h0rked packages being installed.

> I guess a GLEP 42 news item would sort of work, but I really wish we
> had tree dependencies.

There're always profiles... But profiles have to be updated long before
3.1 features are in use, to give people time to upgrade.

> Another option would be to make overlay maintainers generate their
> own metadata.

Probably not viable. Metadata generation moves hosting an overlay from
something you do with a VCS to a complicated procedure involving
several interacting tools -- it's complicated enough that even the way
it's done for gentoo-x86 doesn't always work properly...

> We're getting into pretty weird territory here -- if you had slotted 
> bash versions, you could do bash-3.0 -n foo.ebuild, bash-3.1 -n 
> foo.ebuild, etc.

That still wouldn't catch a lot of things... Unfortunately repoman
can't replace developer knowledge.

Short of persuading upstream to add a feature that makes bash able to
die if it detects you using features added in a version newer than the
one you tell it, there's not much that can be done beyond educating
developers, restricting newer bash features to newer EAPIs and using
GLEP 55 to handle the metadata generation problem.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]