Proposal to move use.local.desc somewhere in /var
 

On 04/24/12 11:21, Robin H. Johnson wrote:
> On Tue, Apr 24, 2012 at 04:11:44PM +0200, Theo Chatzimichos wrote:
>> log from #gentoo-portage: <tampakrap> zmedico: (random idea) would
>> it make sence to generate local.use.desc in /var/cache, or
>> somewhere in /var, but out of the tree?
> 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.

Additionally, if we move the file, euse will need to be updated as well
and get pushed out to a stable version of gentoolikit.

The euse rewrite is on the roadmap for gentoolkit-0.3.1 which doesn't
have a release date yet since the primary contributors have been busy
with other things.

Regards,
Paul

PS: The gentoolkit overlay
(http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=summary)
is open to all Gentoo developers. The only requirement for committing
to the gentoolkit branch is to pick up any pieces if you break
something. Note: the gentoolkit-dev branch has tighter restrictions and
access to it is controlled by idl0r.

Proposal to move use.local.desc somewhere in /var
 

On Tuesday 24 April 2012 12:45:22 Paul Varner wrote:
> On 04/24/12 11:21, Robin H. Johnson wrote:
> > On Tue, Apr 24, 2012 at 04:11:44PM +0200, Theo Chatzimichos wrote:
> >> log from #gentoo-portage: <tampakrap> zmedico: (random idea) would
> >> it make sence to generate local.use.desc in /var/cache, or
> >> somewhere in /var, but out of the tree?
> >
> > 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.
>
> Additionally, if we move the file, euse will need to be updated as well
> and get pushed out to a stable version of gentoolikit.
>
> The euse rewrite is on the roadmap for gentoolkit-0.3.1 which doesn't
> have a release date yet since the primary contributors have been busy
> with other things.

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.
-mike

Proposal to move use.local.desc somewhere in /var
 

On Tue, Apr 24, 2012 at 1:32 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> 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.

++

Any time I add a new use flag/etc the first thing I do is look for how
other packages accomplish the same thing. No sense writing scripts
when we already have one that does the job.

Rich

Proposal to move use.local.desc somewhere in /var
 

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. -mike

Agreed. I don't think it's a good idea to lose the ability to script against
the tree from bash.

Portage itself has always made it easy for the user to write custom sys-
admin scripts, and use.local.desc aids in that.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Proposal to move use.local.desc somewhere in /var
 

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.
-mike

Proposal to move use.local.desc somewhere in /var
 

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 ;-)