[gentoo-dev] Improved ebuild information

[gentoo-dev] Improved ebuild information

[Daniel Stiefelmaier]

Hi!

I just opened this in gentoo-portage-dev, but Jason Stubbs told me my 
ideas are either bad or belong to THIS list, so i try my luck again...

I'd like to have a functionality that prints out what the useflags of a 
ebuild are good for. Some are obvious, others are not. Example:
The useflag "xprint" sounds like printing support, but doesn't tell if 
you need it if you use cups or the kde-printing system or... whatever.
Jason stated:

Take the USE flag "perl", for example. It has the description "Adds 
support/bindings for the Perl language." but for mysql setting it enables the 
installation of some support scripts that just happen to be written in perl.


Another thing is, that i'd like to get some additional information on 
some ebuilds.
Like HOWTOs, known issues, configuration help, related ebuilds (not 
dependant but useful together)
In my opinion, the easiest way would be a wiki.
Ebuilds could contain an additional field "EBUILDNOTES" or the like, 
providing the URL.
An even more simple way would be to have portage tools (eix, emerge) 
print an automatically generated link like
http://www.gentoo-wiki.com/Ebuild:www-client/mozilla-firefox
as mediawiki pages always have a discussion page attached, this could be 
used to get in touch with the maintainers of that package. (Only if they 
want that. This could be noted on the page)

thanks for reading and answering :)

Caliga
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Improved ebuild information

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

On Sat, 01 Oct 2005 22:19:39 +0200 Daniel Stiefelmaier
<mail@stiefelweb.de> wrote:
| I'd like to have a functionality that prints out what the useflags of
| a ebuild are good for. Some are obvious, others are not. Example:
| The useflag "xprint" sounds like printing support, but doesn't tell
| if you need it if you use cups or the kde-printing system or...
| whatever.

We've discussed adding this to metadata.xml a few times in the past,
but every time there was opposition from a vocal minority of one who
claimed that USE flags should always do exactly the same thing for
every package.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Improved ebuild information

[Simon Stelling]

Hi,

Daniel Stiefelmaier wrote:
> In my opinion, the easiest way would be a wiki.

Indeed. But why do you need to modify all the ebuilds?

> An even more simple way would be to have portage tools (eix, emerge) 
> print an automatically generated link like
> http://www.gentoo-wiki.com/Ebuild:www-client/mozilla-firefox
> as mediawiki pages always have a discussion page attached, this could be 
> used to get in touch with the maintainers of that package. (Only if they 
> want that. This could be noted on the page)

Wikis are very popular, but they aren't the solution to every problem in the 
world. If you want to contact the maintainer, write a mail, use IRC, or assign 
bugs to them, but why do we need another (communication) channel?
It'd be great if you could animate people to concentrate useful information 
about a package in a certain place, but that's really not the job of an ebuild 
or portage.

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Improved ebuild information

[Daniel Stiefelmaier]

>We've discussed adding this to metadata.xml a few times in the past,
>but every time there was opposition from a vocal minority of one who
>claimed that USE flags should always do exactly the same thing for
>every package.
>  
>
why do minorities rule?
Actually i agree that in general use flags should have a consistent meaning.
But anyway, if "perl" adds support for perl, the user might want to know 
what it is good for in this package. or "plugins" could list the plugins 
that would be added.

What tool ever would display the use flags description, it could use 
those from
/usr/portage/profiles/use.desc by default, which may be overwriten in 
metadata.xml

greetings,
Caliga
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Improved ebuild information

[Daniel Stiefelmaier]

>> In my opinion, the easiest way would be a wiki.
>
>
> Indeed. But why do you need to modify all the ebuilds?

do i have to? of course it is not necessary to modify 10k ebuilds in a 
week. The line could be added on the next regular update. And as said 
below, it could also be generated automatically by the tool that reads 
the packages metadata.

> Wikis are very popular, but they aren't the solution to every problem 
> in the world. If you want to contact the maintainer, write a mail, use 
> IRC, or assign bugs to them, but why do we need another 
> (communication) channel?

You're right, maybe that discussion thing is not so useful. The only 
thing advantage i see is that the inhibition to participate is very low 
for a wiki. I helped with inkscape.org and met people that never use 
CVS, IRC, Jabber... Those can still write in the wiki. And still, if the 
discussion page should not be used for feedback, maintainers could state 
how they prefer to be contacted.

> It'd be great if you could animate people to concentrate useful 
> information about a package in a certain place, but that's really not 
> the job of an ebuild or portage.

That sounds like
"your target is good, your way may work, but your way is wrong. i don't 
know the right way"

I just can't understand what is so wrong with providing metadata with a 
package. what is metadat.xml then good for?

Above you said, it was good to have relevant information concentrated at 
a specific place.
Just a half hour before you said, the defined way to get such 
information is google.
Now, what? Google doesn't concentrate.

All that has to be done is create a way to print the path to a wiki-page.
Maybe auto-created by eix. Or maybe a new tool named "einfo" that prints 
the information included in metadata.xml.

greets,
Caliga
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Improved ebuild information

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Ok really first off, I am not a gentoo developer, just to let you know :)

First off, everything here is basically taken out of context from
gentoo-portage-dev, so the only sane responses ( to this mail, not the
other one, which was different ) are going to be from people who read both.
> 
>>> In my opinion, the easiest way would be a wiki.
>>
>>
>>
>> Indeed. But why do you need to modify all the ebuilds?
> 
> 
> do i have to? of course it is not necessary to modify 10k ebuilds in a
> week. The line could be added on the next regular update. And as said
> below, it could also be generated automatically by the tool that reads
> the packages metadata.
> 

Regardless of where this data is going, SOME{ONE,THING} has to compile
it all.  You spoke on the other ML of HOW-TO links and all manner of
info.  That info is great.  The problem is convincing ebuild developers
to compile the data in the first place, and keep it accurate.  That is
why we suggested you try your ideas here.  Writing this stuff into a
tool or patching portage is useless if no one compiles/updates this
information.

> All that has to be done is create a way to print the path to a wiki-page.
> Maybe auto-created by eix. Or maybe a new tool named "einfo" that prints
> the information included in metadata.xml.
> 
> greets,
> Caliga

Case 1: Project specific things -> Homepage, guides, HOW-TO's
I like what you are looking for, however I don't think it should be a
Gentoo-specific project.  If one was to make some sort of online
repository of packages and associated helpful guides on using them, that
would be cool.  Even cooler would be if it stood alone from Gentoo ( not
 a gentoo-only project ).  Then every distro could use it, along with
most other UNIXes.

Then you can make a command-line tool or whatnot to query the on-line
database for the information you are looking for.

In any case, I personally don't believe any of this belongs in portage,
metadata.xml or wherever.  Portage's job is to install packages.  I
don't think many people want tons of irrelevant data in the tree, most
people have no problem using a search engine to find it anyway.

Case 2: USE flag specific things.
This is more tricky.  In the current version of portage USE flags are
the only way to enable things on a per-package basis.  This gives us
wonderful things like USE="debug" which is just ass-backwards.  People
use USE flags for things that in most cases aren't meant for USE flags
or go against the global USE flag usage.

You will get cases where USE flag usage is abnormal.  In that case I'd
file bugs against respective packages ( aka, when a global USE flag is
used in a way that doesn't jive with that USE flag's global usage. ).
If you want to query what flags do, there are utilities for that ( ufed,
pyfed? ).  If you want more descriptive usage of USE flags, bug the
ebuild developers to add more text to the appropriate file, or read the
ebuild.

Case 3: Update Paths
For major packages Gentoo generally does a decent job providing upgrade
documentation.  Either the lead dev for that herd/project will write it
up in their devspace, or put it somewhere.  It's often printed at
install time as well, and there are tools to catch all those handy
messages :)
However there are many smaller packages that don't get this kind of
support and you are sometimes left fending for yourself a bit as to
figuring stuff out, or the solution to your problem is printed at
install time ( by install time, I mean post_inst() in portage terms ).
I've already had that argument on this list though, and it basically
came down to better gentoo commit messages and the fact that the gentoo
developers are not responsible for keeping me informed about my packages
and whether this upgrade breaks them.  And honestly, I understand that.

Part of the coolness/problem with gentoo is that you are basically left
as your own system administration.  This isn't redhat where you are
handheld through everything.  Many people get along that way on gentoo,
stuff breaks, they reinstall, end of story.  If you are upgrading
package foo and you don't know if it's important or not, or if it will
break your system you may want to go and check it out.  What does foo
do, what depends on foo ( equery and gentoolkit )?  Check
bugs.gentoo.org or foo's bugzilla for open bugs and check foo's
Changelog ( the package changelog mind, not the gentoo changelog ).

Good Luck,

Alec Warner ( antarus )
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQz9HamzglR5RwbyYAQLiLw//epYhdGOnSM2KUC8hFRkVin4f+KDPNxf1
QvbbfX3gaEfryY2PymcjoOmfWYzySPD6SJhrETnscVMU3lSS26xFSuKdSP+T66rK
a9zvO+JeVn+GDm+dyVLjZxtJTLcv23bCzwrS4EcNVpT33iV0OkYkKHIKPqcGh02O
GxMmKi3SD5wz6mJYzm9tDAdCxsb7g3TaWJlpUm99wvkcf+JlZLSomz3odxCB7mh8
bQqcpyCyrpdpD/FnrE6GQ68NTg2Axfsck85SwcGdJAgwR7yi9pr3ZSKUZKe19AoY
Fz/xQIKIXAlUzRHdAIP3k/nTWawXU0+pucsWJy6S84qsJ+1GIY2EwWU8wpd51llc
k6vPTb+k7X9IGo2uNQvyqIIsHruw9Qi0ZiswF8r8d4gZarBBzaTixoK9ThGU/uvg
zLdfYS+1VeIB/3F1MZ3DW4heVGPriZ9H+xxjG9seD5CbqsT2gIVGeyYVwkzx+8LT
N6Pz6PiUb1OxZoXyOyLCneE/JsEN3UTFBgpbfqUb061N+0eTPyI+46juuF+N50cE
g1fcDnvlGVOYvCGRbaursK2HNK/TqBcXoz0xMB10eJkuh+TX5triK6Xhgaxn51gc
x1m2GzZ58K2th0xlsCw/0mk/kILvHYN9Sb8hk/cHEoHg2QnxrdyoPr9ecoG+StHM
FgqIJvNeNxE=
=9WY7
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Improved ebuild information

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]

On Sun, 2005-10-02 at 02:10 +0200, Daniel Stiefelmaier wrote:
> >We've discussed adding this to metadata.xml a few times in the past,
> >but every time there was opposition from a vocal minority of one who
> >claimed that USE flags should always do exactly the same thing for
> >every package.
> >  
> >
> why do minorities rule?
> Actually i agree that in general use flags should have a consistent meaning.
> But anyway, if "perl" adds support for perl, the user might want to know 
> what it is good for in this package. or "plugins" could list the plugins 
> that would be added.
> 
> What tool ever would display the use flags description, it could use 
> those from
> /usr/portage/profiles/use.desc by default, which may be overwriten in 
> metadata.xml

Well, I think that it may be easier to simply add this information to
use.local.desc, as it already defines local USE flags.  The idea would
be that use.local.desc overrides use.desc when there is a conflict.
Then portage could, via a flag, show the use descriptions for each USE
flag per package.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Improved ebuild information

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

On Sat, 2005-10-01 at 21:22 +0100, Ciaran McCreesh wrote:
> On Sat, 01 Oct 2005 22:19:39 +0200 Daniel Stiefelmaier
> <mail@stiefelweb.de> wrote:
> | I'd like to have a functionality that prints out what the useflags of
> | a ebuild are good for. Some are obvious, others are not. Example:
> | The useflag "xprint" sounds like printing support, but doesn't tell
> | if you need it if you use cups or the kde-printing system or...
> | whatever.
> 
> We've discussed adding this to metadata.xml a few times in the past,
> but every time there was opposition from a vocal minority of one who
> claimed that USE flags should always do exactly the same thing for
> every package.
> 

I guess I am one of this 'minority'.  The question I just want to have
answered, is how the hell are you going to get a system up sanely (and
without tweaking /etc/portage/package.use) if besides the 350 global USE
flags, and the 1200 local USE flags, you now have to worry about global
USE flags meaning different things for every package?

As for the 'xprint' USE flags ... I guess the description is
deceptive .. its support for X11's printing system (or should be).
'cups' is for cups support, etc.


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Improved ebuild information

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

On Wed, 05 Oct 2005 20:03:54 +0200 Martin Schlemmer
<azarah@nosferatu.za.org> wrote:
| I guess I am one of this 'minority'.  The question I just want to have
| answered, is how the hell are you going to get a system up sanely (and
| without tweaking /etc/portage/package.use) if besides the 350 global
| USE flags, and the 1200 local USE flags, you now have to worry about
| global USE flags meaning different things for every package?

Not so big a deal as you might think. For example, the behaviour of the
perl, python and ruby USE flags is in general consistent, but some
people think you need to turn on those flags to enable editing perl /
python / ruby files in Vim. This isn't the case -- the flags handle
plugins written *in* the respective languages, not for. So so long as
metadata.xml (or whatever) is only used to be more specific than the
existing use.*.desc, it's not an issue...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Improved ebuild information

[R Hill]

Martin Schlemmer wrote:
> On Sat, 2005-10-01 at 21:22 +0100, Ciaran McCreesh wrote:
>> We've discussed adding this to metadata.xml a few times in the past,
>> but every time there was opposition from a vocal minority of one who
>> claimed that USE flags should always do exactly the same thing for
>> every package.
>>
> 
> I guess I am one of this 'minority'.  The question I just want to have
> answered, is how the hell are you going to get a system up sanely (and
> without tweaking /etc/portage/package.use) if besides the 350 global USE
> flags, and the 1200 local USE flags, you now have to worry about global
> USE flags meaning different things for every package?

By using package specific USE flag descriptions stored in metadata.xml 
to overlay those in use.desc and use.local.desc.  This info would be 
output by the currently existing utilities that provide USE flag info 
(euse, equery, ufed/used, etc).  I don't think any changes to portage 
would be needed.  This would be an opt-in feature - only those 
maintainers who want this support would need to implement it.  If no 
metadata descriptions exist then they're pulled from use.desc and 
use.local.desc just as they are now.

Global USE flags already do mean different things for every package. 
Just look at 'debug' or 'doc' ;).  Having more information available 
just makes administration easier.

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Improved ebuild information

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

On Wed, 2005-10-05 at 15:13 -0600, R Hill wrote:
> Martin Schlemmer wrote:
> > On Sat, 2005-10-01 at 21:22 +0100, Ciaran McCreesh wrote:
> >> We've discussed adding this to metadata.xml a few times in the past,
> >> but every time there was opposition from a vocal minority of one who
> >> claimed that USE flags should always do exactly the same thing for
> >> every package.
> >>
> > 
> > I guess I am one of this 'minority'.  The question I just want to have
> > answered, is how the hell are you going to get a system up sanely (and
> > without tweaking /etc/portage/package.use) if besides the 350 global USE
> > flags, and the 1200 local USE flags, you now have to worry about global
> > USE flags meaning different things for every package?
> 
> By using package specific USE flag descriptions stored in metadata.xml 
> to overlay those in use.desc and use.local.desc.  This info would be 
> output by the currently existing utilities that provide USE flag info 
> (euse, equery, ufed/used, etc).  I don't think any changes to portage 
> would be needed.  This would be an opt-in feature - only those 
> maintainers who want this support would need to implement it.  If no 
> metadata descriptions exist then they're pulled from use.desc and 
> use.local.desc just as they are now.

Here's my question... use.local.desc is already package-specific, so why
would we need yet *another* place to put package-specific definitions?
Would it not be enough to have use.local.desc overlay on use.desc?  If
package foo uses global USE flag bar in a way different from the
description in use.desc, then it should list the USE flag in
use.local.desc with the correct description for that package.

> Global USE flags already do mean different things for every package. 
> Just look at 'debug' or 'doc' ;).  Having more information available 
> just makes administration easier.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Improved ebuild information

[Bruno]

On Monday 10 October 2005 14:53, Chris Gianelloni wrote:
>
> Here's my question... use.local.desc is already package-specific, so why
> would we need yet *another* place to put package-specific definitions?
> Would it not be enough to have use.local.desc overlay on use.desc?  If
> package foo uses global USE flag bar in a way different from the
> description in use.desc, then it should list the USE flag in
> use.local.desc with the correct description for that package.
>
The additionnal info about USE flags should not be what is this or that USE 
flag used differently for, but rather what *exactly* does the use-flag 
influence. What exact features of the program are enabled/disabled/changed by 
the given USE flag.
Some USE flags are used to either compile against a lib that's shipped with a 
package or with the system version of that lib. Would be useful to know.

Then there are USE flags like static which are very unprecise. Do they mean 
that the program is 100% stand-alone (e.g. does not link against any lib) or 
does it have to do with *.a, *.la files being installed, or just reduce the 
count of libs linked against...

In addition, providing the info in the package metadata is cleaner as 
information about a given package is in one place, and there is not one file 
with 1k lines with many USE flags and their use for each and every package.

The aim is to allow to know what happens without reading the ebuild AND the 
configure script and makefiles of a package.

Bruno

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Improved ebuild information

[Apreche]

Bruno <bonbons67 <at> internet.lu> writes:

> 
> On Monday 10 October 2005 14:53, Chris Gianelloni wrote:
> >
> > Here's my question... use.local.desc is already package-specific, so why
> > would we need yet *another* place to put package-specific definitions?
> > Would it not be enough to have use.local.desc overlay on use.desc?  If
> > package foo uses global USE flag bar in a way different from the
> > description in use.desc, then it should list the USE flag in
> > use.local.desc with the correct description for that package.
> >
> The additionnal info about USE flags should not be what is this or that USE 
> flag used differently for, but rather what *exactly* does the use-flag 
> influence. What exact features of the program are enabled/disabled/changed by 
> the given USE flag.
> Some USE flags are used to either compile against a lib that's shipped with a 
> package or with the system version of that lib. Would be useful to know.
> 
> Then there are USE flags like static which are very unprecise. Do they mean 
> that the program is 100% stand-alone (e.g. does not link against any lib) or 
> does it have to do with *.a, *.la files being installed, or just reduce the 
> count of libs linked against...
> 
> In addition, providing the info in the package metadata is cleaner as 
> information about a given package is in one place, and there is not one file 
> with 1k lines with many USE flags and their use for each and every package.
> 
> The aim is to allow to know what happens without reading the ebuild AND the 
> configure script and makefiles of a package.
> 
> Bruno
> 

I agree with the people who say that a USE flag should do the same thing no
matter which package it is associated with. But it is true there are instances
where a USE flag does something different. Just look at the example about the
perl flag on mysql that is noted above. That tells me that maybe that flag on
mysql shouldn't be the perl flag, but some other flag pertaining to what those
scripts do, not what they are written in. So step one is to make it so a flag 
always does the same thing no matter what ebuild it is associated with.

However, there is a problem that many USE flags are undocumented or difficult to
find documentation on. There are lots of flags that are seriously great
mysteries to me. Especially with packages like mplayer which has a zillion
flags. Also, even though I might know generally what a flag does I wont know
specifically how that effects this package. So what I propose is that each flag
has a general description in use.desc as they do now. But for each individual
ebuild there will be detailed descriptions of each flag the maintainer can put
in if they want. So the one sentence summaries of what a flag does will be
there, but you can easily access a multi-sentence, detailed, e-build specific
description when you are lost. 

Let's do an example. xscreensaver, mplayer and gdm all respect the xinerama use
flag. And it is fair to say that on all of these the flag adds support for
xinerama to the package, so changing the use flag is unecessary. However, on
mlpayer and on gdm you could be more precise and say that flag adds support for
selecting which xinerama screen the program displays on. Whereas with
xscreensaver the flag allows you to display multiple instances of the
screensaver, one per xinerama screen, as opposed to one instance that spans the
entire full screen. 

I think it's pretty obvious how that more specific information can be helpful to
users. I actually know a few people that have xinerama but purposefully don't
apply the xinerama flag to xscreensaver because they prefer a single instance of
the screensaver stretched out. That sort of documentation is very useful and
desperately needed in portage.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Improved ebuild information

[R Hill]

Chris Gianelloni wrote:

> Here's my question... use.local.desc is already package-specific, so why
> would we need yet *another* place to put package-specific definitions?
> Would it not be enough to have use.local.desc overlay on use.desc?  If
> package foo uses global USE flag bar in a way different from the
> description in use.desc, then it should list the USE flag in
> use.local.desc with the correct description for that package.

That's another good idea, and i think it could produce the same results. 
  The only downside I can think of is that use.local.desc wouldn't allow 
for version-specific flags.  But 'equery uses' already solves this as it 
only displays defs for the flags in the IUSE of the ebuild being 
queried.  The only case not covered is if the same flag is used in two 
versions of a package to mean different things, and i don't see that 
happening.

euse is a bit different, but still not a problem.  right now it does this:

   root ~ #  euse -i mozilla
   global use flags (searching: mozilla)
   ************************************************************
   [-    ] mozilla - Adds mozilla support

   local use flags (searching: mozilla)
   ************************************************************
   no matching entries found


it could do this instead:


   root ~ #  euse -i mozilla
   global use flags (searching: mozilla)
   ************************************************************
   [-    ] mozilla - Adds mozilla support

   local use flags (searching: mozilla)
   ************************************************************
   [-    ] mozilla (app-fake/fooapp):
   builds the optional mozilla browser plugin

   [-    ] mozilla (app-fake/someotherapp):
   use embedded mozilla engine to render newsfeeds in html

   [-    ] mozilla (app-fake/yetanotherapp):
   summon giant lizard to invade Tokyo


actually i just realized this already works with euse, no changes 
necessary. :D

thoughts/suggestions/kicksinthenuts? what other than equery would need 
to be fixed to recognize the overlay?  is there anything that would 
explicitly break if a USE flag was in both use.desc and use.local.desc?

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Improved ebuild information

[Thomas de Grenier de Latour]

On Mon, 10 Oct 2005 13:23:29 -0600
R Hill <dirtyepic.sk@gmail.com> wrote:

>  what other than equery would need to be fixed to recognize
> the overlay?  is there anything that would explicitly break if a
> USE flag was in both use.desc and use.local.desc?
> 

Last time this feature was discussed here, i've implemented it, and
in addition to equery i've also touched emerge (new options to
display some flag descriptions) and repoman (no behavioral change
iirc, just some refactoring). It was bug #84884.

--
TGL.
-- 
gentoo-dev@gentoo.org mailing list