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

[Donnie Berkholz <dberkholz@gentoo.org>]

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

On 17:02 Thu 22 Jan     , Ciaran McCreesh wrote:
> On Thu, 22 Jan 2009 08:56:23 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > Can this be fixed by adding bash dependencies to things using new 
> > features? As long as we keep them out of the build path of bash,
> > things ought to work.
> 
> 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.

I guess a GLEP 42 news item would sort of work, but I really wish we had 
tree dependencies. Another option would be to make overlay maintainers 
generate their own metadata.

> > Then we could add a repoman check for new features, if we wanted.
> 
> Can't do that unless you write a feature-complete bash parser and
> pretend-execute every possible path an ebuild can take...

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.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

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