FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-18-2012, 05:56 PM
Ulrich Mueller
 
Default DESCRIPTION in eclasses

Many eclasses (eutils being the most prominent example) contain:
DESCRIPTION="Based on the ${ECLASS} eclass"

Is this of any use?

Ulrich
 
Old 07-18-2012, 06:15 PM
Ciaran McCreesh
 
Default DESCRIPTION in eclasses

On Wed, 18 Jul 2012 19:56:56 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> Many eclasses (eutils being the most prominent example) contain:
> DESCRIPTION="Based on the ${ECLASS} eclass"
>
> Is this of any use?

The reason that sort of thing is there is because in the olden days
before we had specs or EAPIs or anything like that, eclasses were
originally designed and implemented as "classes" in an OO type manner.
The idea was that there would be a "base" eclass, and then you'd derive
"kde", "gnome" etc eclasses from there, all in a nice hierarchy, and
you'd be expected to "override" variables like DESCRIPTION as you go
down the tree.

As it turns out, eclasses ended up being used in a completely different
way. But you still see bits of the original idea cropping up, such as
in the words "class" and "inherit" and "base".

--
Ciaran McCreesh
 
Old 07-19-2012, 06:57 AM
Ulrich Mueller
 
Default DESCRIPTION in eclasses

>>>>> On Wed, 18 Jul 2012, Ciaran McCreesh wrote:

>> Many eclasses (eutils being the most prominent example) contain:
>> DESCRIPTION="Based on the ${ECLASS} eclass"
>>
>> Is this of any use?

> The reason that sort of thing is there is because in the olden days
> before we had specs or EAPIs or anything like that, eclasses were
> originally designed and implemented as "classes" in an OO type manner.
> The idea was that there would be a "base" eclass, and then you'd derive
> "kde", "gnome" etc eclasses from there, all in a nice hierarchy, and
> you'd be expected to "override" variables like DESCRIPTION as you go
> down the tree.

> As it turns out, eclasses ended up being used in a completely different
> way. But you still see bits of the original idea cropping up, such as
> in the words "class" and "inherit" and "base".

Thanks, this explains why these DESCRIPTIONs are there.

But history left aside, are they still useful today? If not, then they
should be removed.

Ulrich
 
Old 07-19-2012, 11:32 AM
Ralph Sennhauser
 
Default DESCRIPTION in eclasses

On Thu, 19 Jul 2012 08:57:09 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> Thanks, this explains why these DESCRIPTIONs are there.
>
> But history left aside, are they still useful today? If not, then they
> should be removed.

DESCRIPTION="Based on the ${ECLASS} eclass" is never a sufficient
description for a package. So clearly pointless here.

Currently only KEYWORDS are banned from eclasses. I would add
DESCRIPTION and LICENSE to this list as well. DESCRIPTION is individual
to the package and it should never be to much work to come up with a
short description and LICENSE in eclasses greatly increases the chances
for the final listed licenses to be wrong. We have seen the latter
happening with the enlightenment.eclass.
 
Old 07-25-2012, 03:57 PM
Mike Frysinger
 
Default DESCRIPTION in eclasses

On Thursday 19 July 2012 02:57:09 Ulrich Mueller wrote:
> >>>>> On Wed, 18 Jul 2012, Ciaran McCreesh wrote:
> >> Many eclasses (eutils being the most prominent example) contain:
> >> DESCRIPTION="Based on the ${ECLASS} eclass"
> >>
> >> Is this of any use?
> >
> > The reason that sort of thing is there is because in the olden days
> > before we had specs or EAPIs or anything like that, eclasses were
> > originally designed and implemented as "classes" in an OO type manner.
> > The idea was that there would be a "base" eclass, and then you'd derive
> > "kde", "gnome" etc eclasses from there, all in a nice hierarchy, and
> > you'd be expected to "override" variables like DESCRIPTION as you go
> > down the tree.
> >
> > As it turns out, eclasses ended up being used in a completely different
> > way. But you still see bits of the original idea cropping up, such as
> > in the words "class" and "inherit" and "base".
>
> Thanks, this explains why these DESCRIPTIONs are there.
>
> But history left aside, are they still useful today? If not, then they
> should be removed.

it depends. for some of the eclasses which are just eblits, it makes sense
(e.g. toolchain/mariadb/etc...). for some plugin based ones, it also makes
sense because the packages are fairly mechanical in nature (e.g. stardict/
linux-kernel/etc...). for core ones (like eutils), i liked it in the past
because it provided a quick way to detect when someone had their inherit order
wrong (although this isn't nearly as common a problem anymore).

so some trimming could probably be done, and we should probably discourage new
eclasses from just copying & pasting, but removing it from all eclasses
doesn't make much sense.
-mike
 

Thread Tools




All times are GMT. The time now is 07:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org