On Sat, 2005-01-22 at 01:23 -0600, Daniel Goller wrote:
> John Mylchreest wrote:
> > Just to make you aware, I dicussed this some time ago and keep meaning
> > to write a GLEP for it.
> > Basically, it was to convert the eclasses so they are located in their
> > own directory under the main eclass name. for example:
> >
> > ${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?
oops ;) Yes it was meant to be in the directory.
>
> >
> > 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?
Exactly the idea.
Its versioned, but not really. Its a logical seperation where required.
>
> (again guys, noone is saying, it is done like so, it is an idea, and one
> i happen to like and would like to see incooperated into whatever the
> solution will be)
>
> >
> > 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
>
> >
> > You will of course need to make sure these are unconditional in the
> > ebuild.
> >
The actual code changes required here are minimal. When I spoke about it
last it had very good feedback. So I'll look at finding time and
definitely definitely write a GLEP for it this coming week.
--
Role: Gentoo Linux Kernel Lead
Gentoo Linux: http://www.gentoo.org
Public Key: gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515
signature.asc
Description: This is a digitally signed message part
