On 17:02 Thu 22 Jan , Ciaran McCreesh wrote: > On Thu, 22 Jan 2009 08:56:23 -0800 > Donnie Berkholz <dberkh...@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
pgpXs2xQuyFmH.pgp
Description: PGP signature
