[gentoo-dev] Re: DESCRIPTION="Based on the ${ECLASS} eclass"

2012-09-15 Thread Duncan 
Zac Medico posted on Sat, 15 Sep 2012 10:01:49 -0700 as excerpted:

> I've gone ahead and removed them. I can't imagine that it will break
> anything. After the change, all of the ebuilds still have non-empty
> DESCRIPTION metadata.

"And there was much rejoicing in gentoo-land!" =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies

2012-09-15 Thread Diego Elio Pettenò 
On 15/09/2012 18:20, Brian Harring wrote:
> Herds, if you want to see what your pkgs would look like, look at 
> http://dev.gentoo.org/~ferringb/unified-dependencies-example/herds/ .

Ruby team could make use of a dep:test and automatic conversion of that :P

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

[gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies

2012-09-15 Thread Brian Harring 
On Sun, Sep 16, 2012 at 12:03:36AM +0200, Micha?? G??rny wrote:
> On Sat, 15 Sep 2012 13:33:18 -0700
> Brian Harring  wrote:
> > To demonstrate the gain of this, we basically take the existing
> > tree's deps, and re-render it into a unified DEPENDENCIES form.
> 
> But in order to do this, we first have to decide exactly what kind
> of dependencies do we want to have. Then convert the tree to
> a separate-variable form with new dependencies. Then we can compare
> it with the DEPENDENCIES form and decide which one is better.

Funny you mentioned that, I just finished tweaking pquery to generate 
real world example unified dependencies; these *are* accurate, just to 
be clear.

Dumps are at 
http://dev.gentoo.org/~ferringb/unified-dependencies-example/ .

Herds, if you want to see what your pkgs would look like, look at 
http://dev.gentoo.org/~ferringb/unified-dependencies-example/herds/ .

If you'd like to see an *example effect* it has on what gets displayed 
to the user (aka, after all major use conditionals are stripped), look 
at 
http://dev.gentoo.org/~ferringb/unified-dependencies-example/user-visible.txt 
; warning, that's a 55MB file.  The syntax in use there isn't great, 
but as said, it's an example.

Total cache savings from doing this for a full tree conversion, for 
our existing md5-cache format is 2.73MB (90 byes per cache entry).  
Calculating the savings from the ebuild/eclass standpoint is dependent 
on how the deps are built up, so I skipped that.

The algorithim used is fairly stupid, but reasonably effectively; 
essentially it intersects the top level of each individual type of 
dep, breaking out common groupings.

In other words, it won't pick up this:
DEPEND="x? ( dev-util/diffball dev-util/bsdiff )"
RDEPEND="x? ( dev-util/diffball )"

and convert it into thus
DEPENDENCIES="
dep:build,run? (
  x? ( 
   dev-util/diffball
   dep:run? ( 
 dev-util/diffball
   )
 )
  )"

Additionally, the form used here makes *no assumption about default 
context*; in any final solution we use, a default context would be 
wise- say build,run.  Again, an example of what I mean.

If we said "in the absense of a context, the default is dep:build,run" 
the following:

DEPEND="dev-util/diffball dev-util/bsdiff"
RDEPEND="dev-util/diffball de-vutil/bsdiff x? ( sys-apps/pkgcore )"
PDEPEND="dev-python/snakeoil"

would be:
DEPENDENCIES="
  dev-util/diffball
  dev-util/bsdiff
  dep:run? ( x? ( sys-apps/pkgcore ) )
  dep:post? ( dev-python/snakeoil )
"

The quicky algo I used assumes no default context, thus it writes 
this:
DEPENDENCIES="
  dep:build,run? (
dev-util/diffball
dev-util/bsdiff
  )
  dep:run? ( x? ( sys-apps/pkgcore ) )
  dep:post? ( dev-python/snakeoil )
"

Etc.

~harring

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc

2012-09-15 Thread Mike Frysinger 
On Tuesday 11 September 2012 14:06:30 Alexis Ballier wrote:
> On Tue, 28 Aug 2012 00:23:11 + (UTC) Mike Frysinger wrote:
> > vapier  12/08/28 00:23:11
> > 
> >   Modified: ChangeLog profiles.desc
> >   Log:
> >   add new s390x profile #345421
> 
> [...]
> 
> > @@ -152,7 +153,7 @@
> > 
> >  x86 default/linux/x86/10.0/server
> > 
> > stable
> > 
> >  # Gentoo/FreeBSD Profiles
> > 
> > -amd64-fbsd default/bsd/fbsd/amd64/9.0 stable
> > +amd64-fbsd   default/bsd/fbsd/amd64/9.0 dev
> > sparc-fbsd  default/bsd/fbsd/sparc/8.2 exp
> > x86-fbsd  default/bsd/fbsd/x86/8.2   dev
> > x86-fbsd  default/bsd/fbsd/x86/9.0   dev
> 
> please be more careful, it is good practice to review the cvs diff output
> before hitting ci when committing to the profiles or eclass directories.

that was only partially an accident.  amd64-fbsd has no business being in 
stable since it has broken deps and has no stable keywords.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Unified DEPENDENCIES concept

2012-09-15 Thread Michał Górny 
On Sat, 15 Sep 2012 13:33:18 -0700
Brian Harring  wrote:

> On Sat, Sep 15, 2012 at 11:06:01PM +1200, Kent Fredric wrote:
> > On 14 September 2012 10:17, Brian Harring 
> > wrote:
> > >> All you need is something in bash that can parse DEPENDENCIES and
> > >> populate *DEPEND , and the underlying guts could be done in
> > >> practically any language without requiring PM specific
> > >> implementations.
> > >
> > > You've got it inverted; if any autopopulation is occuring,
> > > *DEPEND -> DEPENDENCIES is the sane form.
> > >
> > > While it definitely *is* possible to render DEPENDENCIES down into
> > > depend/rdepend (after all, the PM has to do exactly this for
> > > resolution), that does /not/ mean doing it in bash is a good idea.
> > >
> > > I'd really not want to try that using labels; using use
> > > conditionals ('dep:run,build? ( targets )') is frankly a bit
> > > easier imo, but still; why do so unless one likes pain?  It
> > > doesn't actually gain us anything via missing the point of
> > > DEPENDENCIES.
> > >
> > > The point of unified DEPENDENCIES var (regardless of the form) is
> > > thus:
> > > 1) ability to specify common deps once, w/out having to use
> > > intermediate vars/copy-pasting/etc.  Think COMMON_DEPEND, and this
> > > should make sense.
> > >
> > > 2) To shift to a form where adding new dependency targets is easy-
> > > whether it be sdepend, fdepend, tdepend, or hdepend (or
> > > ONE-RING-DEPEND to rule them all).  This actually is rather
> > > important; for the average 95% case, devs won't actually have to
> > > pay much attention to those vars; but for those of us a bit
> > > further out (cross compilation, heavy parallelization, etc) those
> > > depend forms are becoming increasingly painful in their absense.
> > >
> > >
> > > Basically, having devs specify DEPENDENCIES in ebuilds, which
> > > then an eclass chunks out into DEPEND/RDEPEND misses the point of
> > > this; it's doable, it's just not particularly sane imo.
> > >
> > > The other way around, having *DEPEND automatically be collapsed
> > > into DEPENDENCIES, however is very sane- it makes
> > > transition/compatibilty for devs bloody simple, while structuring
> > > it so we can do further enhancements.
> > >
> > > ~harring
> > >
> > 
> > 
> > Sure, but at least this makes it a viable proof-of-concept without
> > needing all the different PM's to implement the new spec first, and
> > due to not being EAPI bound when done this way, means you can just
> > do it and have it work both now and in the future.
> >
> > And because of this "experimental" nature, you don't have to do
> > *ALL* the parsing in bash, you could make the eclass use some
> > external code to parse it and spit it out, and simply have the
> > eclass depend on that external program regardless.
> >
> > I agree that long term, a Unified DEPENDENCIES implementation is the
> > way forward, but if you want to convince people, having something
> > which has been demonstrated and tested in a real world setting goes
> > a long way.
> 
> Honestly, QA would be well within their rights to kick anyone who did 
> this, *hard* in the shins.
> 
> I understand your notion- specifically proof of concept, show the 
> data, etc; I just think you've still got inverted, too focused on 
> trying to do it in bash.
> 
> To demonstrate the gain of this, we basically take the existing
> tree's deps, and re-render it into a unified DEPENDENCIES form.

But in order to do this, we first have to decide exactly what kind
of dependencies do we want to have. Then convert the tree to
a separate-variable form with new dependencies. Then we can compare
it with the DEPENDENCIES form and decide which one is better.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] doheader function for EAPI 5?

2012-09-15 Thread Zac Medico 
On 08/31/2012 01:20 AM, Ulrich Mueller wrote:
> Hi all,
> 
> A new "doheader" (and "newheader") helper function is on our list of
> possible EAPI 5 features. It would be very easy to implement, just
> copy the code from doconfd or doenvd.
> 
> However, this function was suggested in Bug 21310 [1] which was filed
> in 2003. The absence of any activity there makes me wonder if anybody
> cares about the feature?
> 
> Ulrich
> 
> [1] 

PMS does not document this, and the current Portage implementation
supports -r since it passes the arguments to doins as noted here:

  https://bugs.gentoo.org/show_bug.cgi?id=21310#c5

-- 
Thanks,
Zac

Re: [gentoo-dev] Unified DEPENDENCIES concept

2012-09-15 Thread Brian Harring 
On Sat, Sep 15, 2012 at 11:06:01PM +1200, Kent Fredric wrote:
> On 14 September 2012 10:17, Brian Harring  wrote:
> >> All you need is something in bash that can parse DEPENDENCIES and
> >> populate *DEPEND , and the underlying guts could be done in
> >> practically any language without requiring PM specific
> >> implementations.
> >
> > You've got it inverted; if any autopopulation is occuring, *DEPEND ->
> > DEPENDENCIES is the sane form.
> >
> > While it definitely *is* possible to render DEPENDENCIES down into
> > depend/rdepend (after all, the PM has to do exactly this for
> > resolution), that does /not/ mean doing it in bash is a good idea.
> >
> > I'd really not want to try that using labels; using use conditionals
> > ('dep:run,build? ( targets )') is frankly a bit easier imo, but still;
> > why do so unless one likes pain?  It doesn't actually gain us
> > anything via missing the point of DEPENDENCIES.
> >
> > The point of unified DEPENDENCIES var (regardless of the form) is
> > thus:
> > 1) ability to specify common deps once, w/out having to use
> > intermediate vars/copy-pasting/etc.  Think COMMON_DEPEND, and this
> > should make sense.
> >
> > 2) To shift to a form where adding new dependency targets is easy-
> > whether it be sdepend, fdepend, tdepend, or hdepend (or
> > ONE-RING-DEPEND to rule them all).  This actually is rather important;
> > for the average 95% case, devs won't actually have to pay much
> > attention to those vars; but for those of us a bit further out (cross
> > compilation, heavy parallelization, etc) those depend forms are
> > becoming increasingly painful in their absense.
> >
> >
> > Basically, having devs specify DEPENDENCIES in ebuilds, which then an
> > eclass chunks out into DEPEND/RDEPEND misses the point of this; it's
> > doable, it's just not particularly sane imo.
> >
> > The other way around, having *DEPEND automatically be collapsed into
> > DEPENDENCIES, however is very sane- it makes transition/compatibilty
> > for devs bloody simple, while structuring it so we can do further
> > enhancements.
> >
> > ~harring
> >
> 
> 
> Sure, but at least this makes it a viable proof-of-concept without
> needing all the different PM's to implement the new spec first, and
> due to not being EAPI bound when done this way, means you can just do
> it and have it work both now and in the future.
>
> And because of this "experimental" nature, you don't have to do *ALL*
> the parsing in bash, you could make the eclass use some external code
> to parse it and spit it out, and simply have the eclass depend on that
> external program regardless.
>
> I agree that long term, a Unified DEPENDENCIES implementation is the
> way forward, but if you want to convince people, having something
> which has been demonstrated and tested in a real world setting goes a
> long way.

Honestly, QA would be well within their rights to kick anyone who did 
this, *hard* in the shins.

I understand your notion- specifically proof of concept, show the 
data, etc; I just think you've still got inverted, too focused on 
trying to do it in bash.

To demonstrate the gain of this, we basically take the existing tree's 
deps, and re-render it into a unified DEPENDENCIES form.

As for adding support to a PM, if we use the use conditional proposal 
of mine, it's bloody simple- the PM already supports it, we just need 
some minor USE_EXPAND adjustments.

~harring

Re: [gentoo-dev] DESCRIPTION="Based on the ${ECLASS} eclass"

2012-09-15 Thread Rick "Zero_Chaos" Farina 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/15/2012 03:59 AM, Michał Górny wrote:
> On Fri, 14 Sep 2012 19:43:42 -0400
> "Rick \"Zero_Chaos\" Farina"  wrote:
> 
>> On 09/14/2012 05:27 PM, Michał Górny wrote:
>>> On Fri, 14 Sep 2012 17:18:16 -0400
>>> "Rick \"Zero_Chaos\" Farina"  wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 09/14/2012 04:56 PM, Ciaran McCreesh wrote:
> On Fri, 14 Sep 2012 16:51:54 -0400
> "Rick \"Zero_Chaos\" Farina"  wrote:
>> I have a personal vendetta on this subject. Several eclasses set
>> a completely worthless description (and even more set a mostly
>> worthless DESCRIPTION) which ends up contaminating the
>> DESCRIPTION for an ebuild when inherit is done after DESCRIPTION
>> is set.
>
> http://article.gmane.org/gmane.linux.gentoo.devel/78813/
>
>> I realize that most of you will find this a little pedantic,
>> however, I find that needing to move my DESCRIPTION to below the
>> inherit often severely affects the readability of the ebuild, and
>> all to avoid a completely (or nearly) worthless DESCRIPTION from
>> contaminating my environment.
>
> You want your inherit line to be as near as the top as possible.
> The only things you should have before the inherit line are EAPI
> and any variables used by eclasses to determine behaviour.
>
>
 I have a nasty habit of writing ebuilds to be both live and
 versioned which requires me to test ${PV} then set things like
 inherit VCS, SRC-URI, and KEYWORDS below.  The large if block
 looks better in my opinion below the settings which are the same
 for all versions, rather than in the middle.

 Yes, it's a readability issue, but the point is, this shouldn't be
 an issue at all.
>>>
>>> Use unifdef. Look at my overlay, and my ebuilds in the tree.
>>>
>>
>> So just so we are clear, everyone but me thinks that
>> DESCRIPTION="Based on the ${ECLASS} eclass" is a completely useful
>> and critically required piece of code?
> 
> No. We agree with you that it is useless but you are saying that with
> a *completely* wrong reasoning.
> 
>> Until that point I'll probably keep bringing this up.
> 
> Don't forget to threaten us that you'll leave Gentoo.

While I may be completely unreasonable in my requests you will never see
those words spoken from me.  If all of you quit I'd develop gentoo
(poorly) by myself and if I was kicked out (which I'll try to avoid)
I'll keep developing Pentoo based on Gentoo as I have been for the last
7 years.  Please don't mistake my belly aching for a lack of dedication
to this project, it is precisely my dedication that causes me to care so
much.

- -Zero
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQVNM/AAoJEKXdFCfdEflKDJ0P/R5cdzIryH3KQdLEsgziBjKr
iBZhDg5W21RzDTZYWyk8rU4I8T84PYgB2hlYteOcbYoBDAA16WXUd6mktcxowJj7
3TJaohedKJl+gOF7y3Ji/i4RJMtdftPfLIqNFiCI+M2UfPS7JjImU68TXtEccYHH
q9XNnHCiZY2dWT71VJf0mIFU/aUEYwsJYLUmNFO6hjKWeItkAdYD+Z4Crz8U31dt
CyTGa9yju0fMCr33aTIlpPKagtBJq6xKz+mHAZUqnbf54ZPam81hcDc/5T3CkfWN
jby8rJeAlRHzVu8DHZcQR1VCpe505FMi759Uzz78cx+8hNrgbcCLEoHaGnmkePl0
hhqPPEZM0IEtGydT2ZNH4UdGEuGufQvsT84Ul3LyKinPoX2iUyvIo9iTroUcRVUh
S0kS4Qiv/iSV2HAK39nM6y5Q7YRVUdzjKNS3Ia8PjPqxr4YIHVzjmj08nyiL1hPM
VAD8tomefb91k9ZtbeHaF/+niX0Ps/skU7Kr0CXZ53B90LvnCVdZ4RjqwcvhYcoH
ZQEAFV3oMr9vd6JIZb30fHFqGzetnOnQHchNqbffP5CBLV0/bfzem1hnXyVAwGHA
OMsYiGtfxVYCYIdLlsc0k15BTeP3D0IqkZYLLlkQbFeeQHskDY40uyfsENw2DrP1
V4YqERQFubPRZgjGpqGT
=LAXF
-END PGP SIGNATURE-

Re: [gentoo-dev] tla.eclass

2012-09-15 Thread Michał Górny 
On Sat, 15 Sep 2012 18:44:06 +0200
Ulrich Mueller  wrote:

> Not used by any ebuild in the tree, and dev-util/tla was removed four
> years ago.
> 
> Remove?

Yes, please.

However, it should be moved to Sunrise; there's one ebuild using it
there.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: DESCRIPTION="Based on the ${ECLASS} eclass"

2012-09-15 Thread Zac Medico 
On 09/15/2012 08:06 AM, Duncan wrote:
> Rick \"Zero_Chaos\" Farina posted on Fri, 14 Sep 2012 19:43:42 -0400 as
> excerpted:
> 
>> If anyone wants to explain to me why that DESCRIPTION line is so
>> critical that it must exist yet not important enough to put something
>> worthwhile in I'm all ears. Until that point I'll probably keep bringing
>> this up.
> 
> Did you read the up-thread link Ciaran posted?
> 
> http://article.gmane.org/gmane.linux.gentoo.devel/78813/
> 
> IOW, it's legacy.  They could probably "disappear", if anybody was 
> willing to spend the time investigating, then fixing anything that broke 
> when the lines "disappeared".  But it's simply easier to go with "don't 
> fix what's not broken", and just leave it be.  Let someone else take that 
> risk.
> 
> But as long as any breakage "magically disappeared" to wherever the 
> DESCRIPTIONs went, I don't expect there'd be many complaints...

I've gone ahead and removed them. I can't imagine that it will break
anything. After the change, all of the ebuilds still have non-empty
DESCRIPTION metadata.
-- 
Thanks,
Zac

[gentoo-dev] tla.eclass

2012-09-15 Thread Ulrich Mueller 
Not used by any ebuild in the tree, and dev-util/tla was removed four
years ago.

Remove?

Ulrich

[gentoo-dev] Re: DESCRIPTION="Based on the ${ECLASS} eclass"

2012-09-15 Thread Duncan 
Rick \"Zero_Chaos\" Farina posted on Fri, 14 Sep 2012 19:43:42 -0400 as
excerpted:

> If anyone wants to explain to me why that DESCRIPTION line is so
> critical that it must exist yet not important enough to put something
> worthwhile in I'm all ears. Until that point I'll probably keep bringing
> this up.

Did you read the up-thread link Ciaran posted?

http://article.gmane.org/gmane.linux.gentoo.devel/78813/

IOW, it's legacy.  They could probably "disappear", if anybody was 
willing to spend the time investigating, then fixing anything that broke 
when the lines "disappeared".  But it's simply easier to go with "don't 
fix what's not broken", and just leave it be.  Let someone else take that 
risk.

But as long as any breakage "magically disappeared" to wherever the 
DESCRIPTIONs went, I don't expect there'd be many complaints...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: DESCRIPTION="Based on the ${ECLASS} eclass"

2012-09-15 Thread Duncan 
Kent Fredric posted on Sat, 15 Sep 2012 23:52:16 +1200 as excerpted:

> If the usecase for this is "Sometimes people will want to write an
> ebuild and not provide a description at all, and don't care that its not
> useful",
> then it shoudn't be supported by a nasty hack in the parent eclass,
> Portage should instead support a missing DESCRIPTION feature.

Ciaranm already posted this link, from an earlier discussion, that 
describes why that thing's there.  It's legacy and it /should/ be gotten 
rid of I think most would agree (I certainly do as a user; it's a hassle 
and an eyesore).  Only nobody has cared to take on the responsibility of 
double-checking to make sure removing it doesn't break anything and of 
fixing anything they miss if it does anyway, so there the cruft still 
sits.

http://article.gmane.org/gmane.linux.gentoo.devel/78813/

Bottom line, I doubt there'd be any complaints if those lines 
"disappeared", as long as anything broken in the process equally 
magically just "got fixed".

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] DESCRIPTION="Based on the ${ECLASS} eclass"

2012-09-15 Thread Kent Fredric 
On 15 September 2012 08:51, Rick "Zero_Chaos" Farina
 wrote:
> ozzie eclass # grep 'DESCRIPTION="Based on the ' *.eclass
> cannadic.eclass:DESCRIPTION="Based on the $ECLASS eclass"
> confutils.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> embassy.eclass:DESCRIPTION="Based on the $ECLASS eclass"
> eutils.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> games.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> gnatbuild.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> gnuconfig.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> libtool.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> linux-mod.eclass:DESCRIPTION="Based on the $ECLASS eclass"
> nsplugins.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> perl-module.eclass:DESCRIPTION="Based on the $ECLASS eclass"
> qmail.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> toolchain-funcs.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"

+1.

There's no use cases I know of where having a description as such is useful.

Either the Eclass should be able to provide a useful DESCRIPTION for
each and every derived ebuild, or it should provide none at all.

Maybe the Eclass has a translation from $P to $DESCRIPTION somehow
that is useful, but "Based on the ECLASS eclass" is about as useful as
DESCRIPTION="An EAPI $EAPI Ebuild" or  just "An Ebuild", or just no
description at all.

If the usecase for this is "Sometimes people will want to write an
ebuild and not provide a description at all, and don't care that its
not useful", then it shoudn't be supported by a nasty hack in the
parent eclass, Portage should instead support a missing DESCRIPTION
feature.


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Unified DEPENDENCIES concept

2012-09-15 Thread Kent Fredric 
On 14 September 2012 10:17, Brian Harring  wrote:
>> All you need is something in bash that can parse DEPENDENCIES and
>> populate *DEPEND , and the underlying guts could be done in
>> practically any language without requiring PM specific
>> implementations.
>
> You've got it inverted; if any autopopulation is occuring, *DEPEND ->
> DEPENDENCIES is the sane form.
>
> While it definitely *is* possible to render DEPENDENCIES down into
> depend/rdepend (after all, the PM has to do exactly this for
> resolution), that does /not/ mean doing it in bash is a good idea.
>
> I'd really not want to try that using labels; using use conditionals
> ('dep:run,build? ( targets )') is frankly a bit easier imo, but still;
> why do so unless one likes pain?  It doesn't actually gain us
> anything via missing the point of DEPENDENCIES.
>
> The point of unified DEPENDENCIES var (regardless of the form) is
> thus:
> 1) ability to specify common deps once, w/out having to use
> intermediate vars/copy-pasting/etc.  Think COMMON_DEPEND, and this
> should make sense.
>
> 2) To shift to a form where adding new dependency targets is easy-
> whether it be sdepend, fdepend, tdepend, or hdepend (or
> ONE-RING-DEPEND to rule them all).  This actually is rather important;
> for the average 95% case, devs won't actually have to pay much
> attention to those vars; but for those of us a bit further out (cross
> compilation, heavy parallelization, etc) those depend forms are
> becoming increasingly painful in their absense.
>
>
> Basically, having devs specify DEPENDENCIES in ebuilds, which then an
> eclass chunks out into DEPEND/RDEPEND misses the point of this; it's
> doable, it's just not particularly sane imo.
>
> The other way around, having *DEPEND automatically be collapsed into
> DEPENDENCIES, however is very sane- it makes transition/compatibilty
> for devs bloody simple, while structuring it so we can do further
> enhancements.
>
> ~harring
>


Sure, but at least this makes it a viable proof-of-concept without
needing all the different PM's to implement the new spec first, and
due to not being EAPI bound when done this way, means you can just do
it and have it work both now and in the future.

And because of this "experimental" nature, you don't have to do *ALL*
the parsing in bash, you could make the eclass use some external code
to parse it and spit it out, and simply have the eclass depend on that
external program regardless.

I agree that long term, a Unified DEPENDENCIES implementation is the
way forward, but if you want to convince people, having something
which has been demonstrated and tested in a real world setting goes a
long way.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] DESCRIPTION="Based on the ${ECLASS} eclass"

2012-09-15 Thread Sergei Trofimovich 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> In my opinion, the text "# @DESCRIPTION" in an eclass is more than
> enough for readability, and setting DESCRIPTION only serves to
> contaminate the environment.  The is especially true for the following
> eclasses that set the DESCRIPTION from the subject:
> 
> ozzie eclass # grep 'DESCRIPTION="Based on the ' *.eclass
> cannadic.eclass:DESCRIPTION="Based on the $ECLASS eclass"
> confutils.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> embassy.eclass:DESCRIPTION="Based on the $ECLASS eclass"
> eutils.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> games.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> gnatbuild.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> gnuconfig.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> libtool.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> linux-mod.eclass:DESCRIPTION="Based on the $ECLASS eclass"
> nsplugins.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> perl-module.eclass:DESCRIPTION="Based on the $ECLASS eclass"
> qmail.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> toolchain-funcs.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> 
> Although these are the ones that make me the most unhappy, I see no
> purpose for setting DESCRIPTION in any eclass as it really serves no
> purpose to source the eclass then source the ebuild 0.01s later and
> overwrite the DESCRIPTION.  Fixing this is not difficult, unlikely to
> affect anything, but will help avoid one tiny little annoyance that
> really looks like a relic from a time long long ago.

Right, it forbids repoman perform DESCRIPTION.missing check
and makes no sense in multiple inheritance case.

metadata/md5-cache:LANG=C fgrep -R "Based on " .
./sys-fs/sysfsutils-2.1.0:DESCRIPTION=System Utilities Based on Sysfs

None of in-tree users relies on the value. Thus you can wipe them while
nobody is watching :]
 
- -- 

  Sergei
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBUQ/UACgkQcaHudmEf86qP3gCfftVveos4vrjFbUFSfqauVjm1
8c8AnRS8K4NG5NttW79RN5P9aYWY+Pju
=oDKV
-END PGP SIGNATURE-

Re: [gentoo-dev] DESCRIPTION="Based on the ${ECLASS} eclass"

2012-09-15 Thread Michał Górny 
On Fri, 14 Sep 2012 19:43:42 -0400
"Rick \"Zero_Chaos\" Farina"  wrote:

> On 09/14/2012 05:27 PM, Michał Górny wrote:
> > On Fri, 14 Sep 2012 17:18:16 -0400
> > "Rick \"Zero_Chaos\" Farina"  wrote:
> > 
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 09/14/2012 04:56 PM, Ciaran McCreesh wrote:
> >>> On Fri, 14 Sep 2012 16:51:54 -0400
> >>> "Rick \"Zero_Chaos\" Farina"  wrote:
>  I have a personal vendetta on this subject. Several eclasses set
>  a completely worthless description (and even more set a mostly
>  worthless DESCRIPTION) which ends up contaminating the
>  DESCRIPTION for an ebuild when inherit is done after DESCRIPTION
>  is set.
> >>>
> >>> http://article.gmane.org/gmane.linux.gentoo.devel/78813/
> >>>
>  I realize that most of you will find this a little pedantic,
>  however, I find that needing to move my DESCRIPTION to below the
>  inherit often severely affects the readability of the ebuild, and
>  all to avoid a completely (or nearly) worthless DESCRIPTION from
>  contaminating my environment.
> >>>
> >>> You want your inherit line to be as near as the top as possible.
> >>> The only things you should have before the inherit line are EAPI
> >>> and any variables used by eclasses to determine behaviour.
> >>>
> >>>
> >> I have a nasty habit of writing ebuilds to be both live and
> >> versioned which requires me to test ${PV} then set things like
> >> inherit VCS, SRC-URI, and KEYWORDS below.  The large if block
> >> looks better in my opinion below the settings which are the same
> >> for all versions, rather than in the middle.
> >>
> >> Yes, it's a readability issue, but the point is, this shouldn't be
> >> an issue at all.
> > 
> > Use unifdef. Look at my overlay, and my ebuilds in the tree.
> > 
> 
> So just so we are clear, everyone but me thinks that
> DESCRIPTION="Based on the ${ECLASS} eclass" is a completely useful
> and critically required piece of code?

No. We agree with you that it is useless but you are saying that with
a *completely* wrong reasoning.

> Until that point I'll probably keep bringing this up.

Don't forget to threaten us that you'll leave Gentoo.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature