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.
that i could see, i asked him why he omited /kernel/ in the second line, to which he replied, it was a mistake, but i didnt want to assume it was if it had a reason
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.
under my proposal you make a new version of the eclass, but no you dont go edit every ebuild that uses that eclass, or in a more precise point, yes you edit EVERY ebuild that uses that NEW eclass, that ONE ebuild that will start to use the new eclass, i wouldnt say the workload isnt affected by it much at all if my proposal would require you to edit 20 ebuilds just cause a new version of a package requires you to actually change the eclass, not the ebuild
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.
here is where idea about links comes back into play, then a simpe change of a link could inherit things like eutils.eclass and games.eclass, because we do have versioned eclasses in tree this is possible
there could be a split solution, system package require absolute inheritance, while packages can use either absolute inheritance or indirect via symlinks
this way a system can still be locked in, you can lock the version of ebuild you want, and lock the appropriate eclass, which people will scream "mix and match, mix and match!"
one solution avoids mix and match but makes people see only one finger saluts coming the way of those who proposed this, the other way they would be seeing less work (not saying either one actually creates all the extra work you fear), but others would fear mix and match
i acknowledge you fear much extra work, and from your points i understand you edit games.eclass all the time and will make sure to have a solution that will not cause a "Berger-style" angry two finger incident (you watch Sex and the City and know what i mean, right? ;)
signature.asc
Description: OpenPGP digital signature
