----- Original Message ----- From: "Marius Mauch" <[EMAIL PROTECTED]> > Ciaran McCreesh wrote: <snip> > As for the new metadata variable, I think it should be a complement to > RESTRICT (not limited to prefix). As the name for this var I suggest > SUPPORTS, so for an ebuild that can install into /usr, $PREFIX and $HOME > it would look like: > SUPPORTS="prefix prefix-home" (as /usr is implicit)
For the values of the SUPPORTS-Variable (i like the name) i'd prefer some words pointing to the package-manager used (primary/secondary/home), fex "secondarypm homepm" or "2ndpm homepm" or the like (more ideas welcome), because /usr is a 'prefix' too. But here's just one point to think of how to avoid redundant information in ebuilds: The SUPPORTS-Variable _will_ be necessary for home-installation, sure. But when an ebuild has KEYWORDS='sparc' and SUPPORTS='2ndpm', this does not automatically imply that it compiles on a 'sparc-solaris' - this keyword has to be added explicitly. But how likely is it that on 'sparc-solaris' portage would be the primary pkg mgr installing into /usr ? So when an ebuild has 'sparc-solaris' in keywords, imo one can assume that it _does_ support "secondarypm" (also look at http://www.gentoo.org/proj/en/glep/glep-0022.html#reasonable-defaults). Or is this assumption too much implicit ? Well, right, this will break the bsd keyworded ebuilds when used with a secondary pm unless they support it, so this would not be a reasonable way to go, just a point to think of (imo installing into primary prefix with a secondary pkg mgr is sth. weird...) ~haubi PS: sorry for beeing offline most of the time, i'm on holiday until May 17, just sporadically reading mail, and completely offline from May 13 -- [email protected] mailing list
