On Sat, 2005-01-22 at 01:23 -0600, Daniel Goller wrote:
> > ${PORTDIR}/eclass/kernel/kernel.eclass
> > ${PORTDIR}/eclass/kernel-2.eclass
>
> why is kernel-2.eclass not also in the dir kernel, is that where it was
> meant to be? if not can you explain the idea behind leaving it one level up?
They are not the same eclass. They are not versions of each other, but
2 distinctly different eclasses.
> > there wouldnt be full versioning support (ie: via an atom) but you would
> > have the benefit of:
> >
> > changelog
> > manifest
> > signing
> > metadata
> > much tidier
>
> sounds really good to me
> the full versioning support could stil be done via a simple 'cp'
> you copy it to next version, and only the next ebuild that needs it
> inherits it, all future ebuilds inherit it till you need to bump the
> eclass again
> sound reasonable?
No. If I *want* to make a change to an eclass that affects all the
packages that inherits it, under your proposal, I would have to make a
new version of the eclass, then edit every single ebuild that inherits
that eclass. The whole *point* of an eclass is to have shared code. To
only have to edit one place to make what would otherwise be very tedious
changes. Your proposal breaks the functionality of eclasses.
> > You could do a logical versioning system however.
> > In kernels case let me propose something like:
> >
> > inherit kernel-${KV_MAJOR}.${KV_MINOR}
> >
> > in which case we can have completely different code between the
> > eclasses.
>
> if you tie the eclass version to the package version or not, either
> choice would give you this flexibility, carry on work in an eclass
> version that wont break any of the ebuilds still using the old eclass
> im sure people would find many uses once we could come up with a final
> solution
This is a case where this works, simply because all kernels are similar,
especially of the same major and minor version.
Now look at games.eclass, which serves several hundred completely
independent packages. Where would versioning help me?
How about eutils.eclass? Just because I want to use the new
domenu/doicon stuff I have to bump every single ebuild that I want to
use it? Does that not defeat the purpose if "inherit eutils" was
already in the ebuild? If I wanted to have to inherit something
different every time a change was made, I would just make a new eclass
entirely.
--
Chris Gianelloni
Release Engineering - Operations/QA Manager
Games - Developer
Gentoo Linux
signature.asc
Description: This is a digitally signed message part
