From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12005 invoked by uid 1002); 1 Jul 2003 15:49:26 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 26573 invoked from network); 1 Jul 2003 15:49:25 -0000 Date: Tue, 1 Jul 2003 17:49:23 +0200 From: Josep Sanjuas To: gentoo-dev@gentoo.org Message-Id: <20030701174923.35cefb97.kl4rkmail@jazzfree.com> In-Reply-To: <200307011505.02533.tdickenson@devmail.geminidataloggers.co.uk> References: <20030701025824.64ecc18a.seemant@gentoo.org> <200307011505.02533.tdickenson@devmail.geminidataloggers.co.uk> X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] Interest Check: Dynamic config files for portage X-Archives-Salt: 908f3c22-8bb1-4965-ad6d-874f96974327 X-Archives-Hash: b1d5d1913ef97ae11c85e3b92b2381a3 On Tue, 1 Jul 2003 15:05:02 +0100 Toby Dickenson wrote: > On Tuesday 01 July 2003 10:58, Seemant Kulleen wrote: > > Hi All, > > > > Before I go and invalidate a bug, I thought I might take the idea around > > here to see if it has any merit in terms of usefulness/interest. > > > > The idea stems from the fact that etc-updating a make.conf file can be a > > bit of a stressful event. And as portage's set of features grows, so too > > will the size of the make.conf file. I get the impression that the > > make.conf file is a little hard to parse, with the huge comment blocks etc > > etc. So my proposal is this: a make.conf.d directory which contains files > > for each section of the make.conf: use, flags, fetch, packagevars. > > Are there any other advantages to having an /etc/make.conf.d?.... I dont see > any. > > If the *only* advantage is to reduce the headache when using etc-update, then > surely we should be looking for improvements to etc-update and sdiff, rather > than changing the structure of one of our core configuration files. > > (And Im not sure the proposed solution will help much anyway.... why should > updating multiple files in /etc/make.conf.d be any easier than updating one > monolithic /etc/make.conf?) > > -- > gentoo-dev@gentoo.org mailing list > > I think there could be more advantages. It would make make.conf faster to parse from scripts, and this might one day become a necessity as it continues to grow. It'd also make portage easier to maintain, because for example, if I want to change the disftile or rsync mirrors then I can edit /etc/make.conf.f/fetch, or whatever its name would be, instead of finding the appropiate vars in the big make.conf. In the files, all flags could have their detailed descriptions, so that you wouldn't need to open another file eg a make.conf.help. After the update, then we could run something like /sbin/portage-update then have a make.conf with only necessary stuff in it. Also, we might have one configuration tool per topic, which is good instead of having each conf tool to deal with the entire make.conf. (And maybe a big setup tool that could call all the more specific others.) Josep Sanjuas -- gentoo-dev@gentoo.org mailing list