On Wed, 2005-02-16 at 06:47 -0600, Brian Harring wrote: > On Wed, Feb 16, 2005 at 07:05:47AM -0500, Mike Frysinger wrote: > > one thing this still assumes is that eclasses/elibs are always written to > > cover many packages ... sometimes (with large packages such as > > gcc/xorg/openoffice), we want shared code just for that one package ... > > wouldnt it make more sense to keep it located in the package directory > > rather > > than elib/ ? > > http://bugs.gentoo.org/show_bug.cgi?id=69714 > > -mike > It's not explicitly covered in the glep. Although I spose a special prefix > in the eclass path could handle it (along > with making inherit a bit wiser). > > fex, inherit local-package/default.eclass > Portage would recognize 'local-package', and look strictly w/in the package's > directory. > > It's been asked in the past (actually was asked for elib just the other > day)... I'm not really much for it though. > It's basically sharing code, but forcing others to not use it. Why is this > desirable? Eg, why limit the code to > just one package?
Because its only gcc/binutils/whatever that uses that (not like kde/gnome/whatever that have many similarities), and some times they change for each version (say gcc-3.3.x will differ much from gcc-3.4.x). Now having only _one_ eclass will be an issue as we will have to add many per-version hacks, which will also be ugly, and adding an eclass for each version or each new big change will make the 100+ eclasses currently even more unmanageable and messy. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa
signature.asc
Description: This is a digitally signed message part
