From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 657D41389E2 for ; Sat, 27 Dec 2014 06:52:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A0BC6E0AB8; Sat, 27 Dec 2014 06:52:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1744BE0A91 for ; Sat, 27 Dec 2014 06:52:50 +0000 (UTC) Received: from [192.168.100.192] (67-203-132-147.static-ip.telepacific.net [67.203.132.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 7C732340545 for ; Sat, 27 Dec 2014 06:52:48 +0000 (UTC) Message-ID: <549E573A.3090104@gentoo.org> Date: Fri, 26 Dec 2014 22:52:42 -0800 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] Re: [PATCH] man pages: note that make.conf can be a directory (463266) References: <1419631307-30949-1-git-send-email-zmedico@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: e873b1c6-4192-4825-85df-dafb738d5da9 X-Archives-Hash: 863386dc7920d2d0d94d4deb61194f4e On 12/26/2014 10:22 PM, Duncan wrote: > Zac Medico posted on Fri, 26 Dec 2014 14:01:47 -0800 as excerpted: > >> Commit 86e75790954e766beba75443d967b2c25055c5b0 added support for >> make.conf to be a directory, but the feature was undocumented. >> Therefore, update the man pages, as suggested in bug #465164, comment >> #9. > > What about other apps that parse make.conf? A note that this might break > compatibility with some of them, and/or with other scripts people > sometimes post on the forums, lists, etc, could be worthwhile. I think this goes without saying. External tools would really be better off calling 'portageq envvar' than parsing make.conf directly. I think it's fine to let people discover such issues themselves, and report bugs for the corresponding tools. Maybe that will help generate some noise that will give the maintainers some incentive to fix those tools. Cluttering our documentation with compatibility notes that will eventually become outdated seems kind of pointless. Also, such notes are not necessarily relevant to all users, so that's another reason I would prefer to omit them. > I believe that's why I chose to stick with a make.conf file that simply > sourced a bunch of other files, instead of simply making it a directory > and sticking all those other files in the dir, when I first read about > the possibility. I have scripts myself that simply source make.conf, > that I'd have to rewrite with a for loop to process a directory. It's > not hard to do, but people haven't had to worry about it and so they > haven't. If people aren't thinking about that when they up and make > make.conf a directory, they might well wish they had! =8^0 Why don't you use 'portageq envvar'? > Most of the others I've made dirs, tho. It's much easier configuring > portage that way, and as I said, my make.conf is already just a bunch of > source directives, giving me pretty much the best of both worlds. =:^) > > (Until I add a new configuration file and forget to add a corresponding > source line for it in make.conf, as I did recently. =:^( ) > > I'll eventually do make.conf as well, but it's not worth worrying about > changing my scripts until all the packages that reference it are known to > handle it. These bug reports for euse, euses, and ufed come to mind: https://bugs.gentoo.org/show_bug.cgi?id=474574 https://bugs.gentoo.org/show_bug.cgi?id=478318 If I actually used any of those tools, then they probably would have been fixed long ago. -- Thanks, Zac