| 1 |
On Mon, 25 Apr 2005 14:47:03 +0100 |
| 2 |
Ciaran McCreesh <ciaranm@g.o> wrote: |
| 3 |
|
| 4 |
> On Mon, 25 Apr 2005 15:27:12 +0300 Marius Mauch <genone@g.o> |
| 5 |
> wrote: |
| 6 |
> | Dan Meltzer wrote: |
| 7 |
> | > I can see the use for a category one, but I can see no point for a |
| 8 |
> | > package-local one, if you're going to have it specific for one |
| 9 |
> | > package, why not just put it in the ebuild, and have no eclass at |
| 10 |
> | > all? |
| 11 |
> | |
| 12 |
> | Actually I'd say the opposite: There is definitely a use for |
| 13 |
> | package-local eclasses, however I don't see the point for |
| 14 |
> | category-local eclasses (especially as that would very funny to get |
| 15 |
> | it working). Example for package-local eclasses? Whenever you define |
| 16 |
> | a function in an ebuild that isn't version specific. |
| 17 |
> |
| 18 |
> Category-specific: app-vim/eclass/vim-plugin.eclass |
| 19 |
> Package-specific: any package with a non-trivial build system that |
| 20 |
> doesn't change too much between versions. |
| 21 |
> |
| 22 |
> Making it work is 'easy', just make inherit first try /cat/pkg/eclass/ |
| 23 |
> then /cat/eclass/ then finally /eclass/ . |
| 24 |
|
| 25 |
well, /cat/eclass will bring us a lot of fun if implemented ;) |
| 26 |
|
| 27 |
Marius |
| 28 |
|
| 29 |
-- |
| 30 |
Public Key at http://www.genone.de/info/gpg-key.pub |
| 31 |
|
| 32 |
In the beginning, there was nothing. And God said, 'Let there be |
| 33 |
Light.' And there was still nothing, but you could see a bit better. |
Archives