From: Steven J Long <slong@rathaus.eclipse.co.uk>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Re: Proposal to move use.local.desc somewhere in /var
Date: Sat, 28 Apr 2012 02:02:07 +0100 [thread overview]
Message-ID: <jnffa5$noh$1@dough.gmane.org> (raw)
In-Reply-To: 201204251151.55728.vapier@gentoo.org
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 ;-)
prev parent reply other threads:[~2012-04-28 0:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-24 14:11 [gentoo-dev] Proposal to move use.local.desc somewhere in /var Theo Chatzimichos
2012-04-24 14:37 ` Mike Frysinger
2012-04-24 14:45 ` Michał Górny
2012-04-24 14:59 ` Brian Dolbec
2012-04-24 15:06 ` Theo Chatzimichos
2012-04-24 16:21 ` Robin H. Johnson
2012-04-24 16:45 ` Paul Varner
2012-04-24 17:32 ` Mike Frysinger
2012-04-24 20:05 ` Rich Freeman
2012-04-25 6:26 ` [gentoo-dev] " Steven J Long
2012-04-25 15:51 ` Mike Frysinger
2012-04-28 1:02 ` Steven J Long [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='jnffa5$noh$1@dough.gmane.org' \
--to=slong@rathaus.eclipse.co.uk \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox