Sorry Ciaran, just replying to all to keep headers in tact and posted to -dev.
On Wed, 2005-02-16 at 15:49 +0000, Ciaran McCreesh wrote: > On Wed, 16 Feb 2005 07:47:57 +0000 John Mylchreest <[EMAIL PROTECTED]> > wrote: > | Further to a previous thread where I said I would get a GLEP ready for > | viewing, please find it here: > | http://dev.gentoo.org/~johnm/files/glep33.txt > > 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. > Two issues we'd have with elibs: > * even things like eutils set a DEPEND, since patch is a dep. > * anything which touches use flags will have to be an eclass, since IUSE > needs to be set. > > 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: versionator (as you well know. I realise it contains no redefined portage functions but see above about proper usage) linux-info (this does redefine, but the kernel_is function is useful in many instances. GNOME have recently used it for example, and linux-info would be mostly better suited an elib) check-reqs another good example of an eclass which would be better suited an elib. 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. 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. > Also, are you really really really sure you can get the transition going > smoothly without forcing a portage update upon everyone? The portage update is only as important as keeping old eclasses around for the lack of proper env handling. the ebuild-compat will be around forever(almost) to prevent this breakage, and will be on a system profile so as of the sync which might break things, ebuild-compat immediately becomes a profile dependency. because of this being provided by newer portage functionality, this wont be pulled in by older portage versions and therefore should remain seamless. This would obviously be better clarified by the people making the portage changes, but on paper I see no issues with this. -- 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
