From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E5Mw8-0000uq-1J for garchives@archives.gentoo.org; Wed, 17 Aug 2005 12:22:28 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7HCKb76000164; Wed, 17 Aug 2005 12:20:37 GMT Received: from ms-smtp-05.tampabay.rr.com (ms-smtp-05-smtplb.tampabay.rr.com [65.32.5.135]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7HCHUpq025186 for ; Wed, 17 Aug 2005 12:17:31 GMT Received: from [192.168.1.50] (57.85.118.70.cfl.res.rr.com [70.118.85.57]) by ms-smtp-05.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id j7HCIIeP008803 for ; Wed, 17 Aug 2005 08:18:18 -0400 (EDT) Message-ID: <4302B638.4090609@gentoo.org> Date: Tue, 16 Aug 2005 23:59:52 -0400 From: Aaron Walker User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050807) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] eselect modules References: <42AD8D53.1080100@gentoo.org> <1124219235.19895.27.camel@cloud.outersquare.org> In-Reply-To: <1124219235.19895.27.camel@cloud.outersquare.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Archives-Salt: 4e05c396-ff99-49c4-bd46-b1cfc515b09e X-Archives-Hash: 9a53d46a6dcfa627b73ddea0ad021a57 Jeremy Huddleston wrote: > I've recently updated opengl-update to use the eselect framework. I > think the team has done a great job as it was extremely easy to port the > bash script to an eselect module. However, when I placed it in the > portage tree, it sparked a little bit of a policy discussion between > myself and the core eselect devs on how to best include modules in the > tree, so I'd like to let other devs chime in as well. > > Firstly if you don't know what eselect is, check out: > http://www.gentoo.org/proj/en/eselect/index.xml > > The eselect developers want to keep all eselect modules in their svn > repository and distributed through a single package (app-admin/eselect). > Their main reasons for this are better QA and less overhead for releases > and merging. QA is my main concern. > > I have a problem with this policy because: > 1) Stability of the modules should not be tied to stability of the core > package. Basically, I'd like to determine when my modules get pushed > into stable without considering how it'll effect the eselect modules of > other developers. Similarly, I don't want bugs in another module > holding up my module from going into stable. agreed. > > 2) Not all users will want all modules. The goal of the eselect project > is to provide a framework to replace java-config, motif-config, > gcc-config, binutils-config, opengl-update, etc, but not all users will > need all modules. > > 3) Some modules require extra files (opengl-update installs header > files, gcc-config installs a wrapper, etc), and the app-admin/eselect > package is not the correct place to provide these files. agreed. > > Also, what should the correct way to introduce these modules into > portage? > Should we keep them in the packages they're replacing > (x11-base/opengl-update)? > Should we place them in a new package in the same category as the script > they're replacing (x11-base/eselect-opengl)? > Should we place them in app-admin/eselect- or perhaps > app-eselect/? Good question. I don't really have a preference. > > Note that for backwards compatibility in all cases, > x11-base/opengl-update will RDEPEND on this eselect module and install a > backwards-compatible frontend to the eselect module until all packages > in portage have been updated to use the eselect module instead. > It's been my opinion from the beginning that not allowing modules to be distributed outside of eselect limits its flexibility. However, I've kept my foot down to this point soley for QA reasons. It'd be a nightmare to keep track of the modules if they were all over the tree in various packages' files/ directories. After thinking about this a bit and reading the other responses you've gotten so far, I think we should keep all the modules in the main subversion repository and allow the modules to be distributed separately (once we have a stable API of course). Yay or nay on this? -- "Summer is butter on your chin and corn mush between every tooth." -Calvin Aaron Walker [ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ] -- gentoo-dev@gentoo.org mailing list