On Wednesday 16 February 2005 19:39, John Mylchreest wrote: > On Wed, 2005-02-16 at 15:49 +0000, Ciaran McCreesh wrote: > > I don't see the need for having eclasses and elibs treated as two > > different things. The way it is now, we can have classes that do export > > vars and eclasses that don't. > > Correct, but eclasses by definition are there to redefine ebuild > behaviour, rather than be a repository of functions. What definition is that? Eclasses are there to keep shared ebuild code in. Function-repository eclasses are a natural form of that, and they've always been around.
Take kde-functions.eclass. It's a purely function-library eclass and has always been that way; rev 1.1 begins with the words, "This contains everything except things that modify ebuild variables and functions" - just like an elib. It was created more than three years ago, just a few months after the first eclasses. (If you're interested in cvs logs, it was called kde-dirs.eclass originally.) eutils.eclass is probably the best-known function repository eclass, and it's been around for 2.5 years, too... > > Is there a good reason for an arbitrary split? > > Most of the perceived problems are speculation or procedural issues, > although to specify a few examples of this: These are examples of eclasses that should become elibs, right? Not examples of these perceived problems. Or am I misunderstanding? > Think of it as a clear definition between behavioural functionality of > an eclass, and the library functionality of an elib. > Shared functions would be better suited in an elib, whereas shared > behaviour an eclass. But why is this separation needed to begin with? What's wrong with the simple concept of an eclass as a generic code module? > elibs may be included into any ebuild, without fear of it changing > anything. if I were to go into versionator.eclass tomorrow and define a > screwy pkg_postrm or some such, it would be most unpleasant. This isn't > much of an argument, but its a passing comment which holds relevance. You could add a screwy pkg_postrm to a new-style eclass, too. How does the separation help us here? After all, if I were to go and change an elib function's behaviour in a screwy way, that'd break things too. We can't prevent people from breaking the tree with bad code. --- I'm all for not having to maintain unlimited backward compatibility, and signing eclasses. But I don't see a need for the elib-eclass separation. The reason given in the GLEP (your mail doesn't seem to add anything to this) is: > Eclasses inherit other eclasses to get a single function- in > doing so, modifying the the exported 'template' (default src_compile, > default src_unpack, various vars, etc). All the eclass designer was after > was reusing a function, not making their eclass sensitive to changes in the > template of the eclass it's inheriting. The eclass designer -should- be > aware of changes in the function they're using, but shouldn't have to worry > about their default src_* and pkg_* functions being overwritten, let alone > the env changes. I don't think elib/eclass separation would help us with this very much. As I wrote above, people will always be able to break eclasses, and elibs too. An eclass policy would be better. Something like: --- - For every eclass, include brief header comment. The comment should as a minimum specify whether the eclass is meant for private use by one developer/team/arbitrary grouping of devs, or is open for public use. - If it's private, its API may change unpredictably and without prior notification to anyone. It's the eclass's owners' business. - If it's public, comments should be added about the intended functionality (so that bugs can be fixed without being treated as new functionality). An eclass's API becomes stable the moment it goes public. Fixes and new functionality (such as non-exported functions) are fine. Changes in exported functions' behaviour, changes in global code, or (most severe) changes to the EXPORT_FUNCTIONS list aren't. Small changes require very thorough checks that all ebuilds using the eclass aren't broken by it. A public eclass change is the same as a change to all ebuilds using it. If the eclass is so widely used that this check isn't easy to make, or if you're unsure of your changes, treat as big change. You're also required to mail a notification to the devs(/teams/herds) of the ebuilds involved, or gentoo-dev for popular eclasses. Big changes (including almost all changes to EXPORT_FUNCTIONS) aren't allowed, period. Create a new eclass that inherits the old one and adds the new code. It's completely safe and a lot easier. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpNBDKRBLjQJ.pgp
Description: PGP signature
