Mike Frysinger wrote: > On Wednesday 25 April 2012 02:26:19 Steven J Long wrote: >> Mike Frysinger wrote: >> > Paul Varner wrote: >> >> Robin H. Johnson wrote: >> >> > Why are we keeping it? I move that we remove it. It's been replaced >> >> > by USE flags in metadata.xml for several years now. >> >> >> >> euse from gentoolkit still uses it since it is written in bash and XML >> >> parsing in bash can be problematic. We really need to get euse >> >> rewritten in python so it can use the portage and gentoolkit API's >> >> before we get rid of the file. >> > >> > it's also a bit of a speed issue. i often want to look at what flags >> > get used >> > across the tree. what's faster: loading + parsing 15000 xml files, or >> > loading 1 file ? shifting it to metadata/ as a cache of all the xml >> > files is probably fine, but i'm not sure dropping it completely is an >> > improvement. >> >> Agreed. I don't think it's a good idea to lose the ability to script >> against the tree from bash. > > technically, you can script with xml files just fine from bash. install > app- text/xmlstarlet and use the `xml` tool.
Oh, I've been a fan for several years[1] :) I still don't want to require it as a dependency, especially when, as you say, it's quick and easy to access a single file per-repo. There's utility in it, and there isn't any real gain in ditching it, beyond not requiring its generation. And since it's been unnoticed for such a long while, it can't be causing any real troubles. So why lose its usefulness? It certainly counts as a file that should be synchronised as part of the repo, though. So if you're going to move it to /var, better to move /usr/portage itself, imo. (This thread feels like it's really about that, tbh, but users can already set it where they want and often just have a separate partition, or if they're bothered have already configured it to /var/portage, so it's more about new users, and whether a baselayout change is worth the hassle.) Regards, Steve. [1] cf: /msg friendlyToaster xml -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
