public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Zac Medico <zmedico@gentoo.org>
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)
Date: Fri, 26 Dec 2014 22:52:42 -0800	[thread overview]
Message-ID: <549E573A.3090104@gentoo.org> (raw)
In-Reply-To: <pan$94a47$8b4b7273$15e0aca9$71815bbc@cox.net>

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


  reply	other threads:[~2014-12-27  6:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-26 22:01 [gentoo-portage-dev] [PATCH] man pages: note that make.conf can be a directory (463266) Zac Medico
2014-12-27  6:22 ` [gentoo-portage-dev] " Duncan
2014-12-27  6:52   ` Zac Medico [this message]
2014-12-29  2:55     ` Duncan
2014-12-29  3:01       ` Zac Medico
2015-01-05 13:12 ` [gentoo-portage-dev] " Alexander Berntsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=549E573A.3090104@gentoo.org \
    --to=zmedico@gentoo.org \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox