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?
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?
(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.
Thanks for your input
Daniel
signature.asc
Description: OpenPGP digital signature
