public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: rfc: logrotate and xinetd use flags
Date: Mon, 25 Apr 2011 05:09:04 +0000 (UTC)	[thread overview]
Message-ID: <pan.2011.04.25.05.09.04@cox.net> (raw)
In-Reply-To: 20110424215823.GA24437@linux1

William Hubbs posted on Sun, 24 Apr 2011 16:58:23 -0500 as excerpted:

> I feel that the current approach (using INSTALL_MASK) to control whether
> these configuration files are installed or not is not well documented.
> We tell people about it on the mailing lists, but I do not know of a
> place where it is documented.

It's documented in the documentation, of course. =:^)

From the make.conf (5) manpage:

INSTALL_MASK = [space delimited list of file names]
    Use  this  variable if you want to selectively prevent certain files
    from being copied into your file system tree.  This does not work on
    symlinks, but only on actual  files.   Useful if  you wish to filter
    out files like HACKING.gz and TODO.gz. The INSTALL_MASK is processed
    just before a package is merged.   Also  supported  is  a
    PKG_INSTALL_MASK  variable  that behaves  exactly  like  INSTALL_MASK
    except that it is processed just before creation of a binary package.

But I agree that isn't as well documented as it might be, despite the 
manpage documentation.  Having it in the handbook's working with portage 
section would certainly add to its visibility. But I'm not sure that 
section, despite being dedicated to portage, is intended to be an 
exhaustive examination of the available settings.  I believe it's entirely 
appropriate to only have that in the manpage, as arguably, people to whom 
the near-first thought when looking for such a feature is NOT to go see 
what the manpage has to say about it, perhaps shouldn't be messing with 
the feature in the first place.

IOW, if it weren't in the manpage, I'd say that's a serious bug, the 
manpage needs fixed.  Since it /is/ in the manpage, and Gentoo's manpages 
are arguably much more accessible than most, additional documentation 
would be nice, but is arguably low priority TRIVIAL/ENHANCEMENT level 
stuff.

> Also, it seems to be an all or nothing arrangement. If I do not want
> logrotate support, I have to set the INSTALL_MASK then if I decide later
> I want it, I have to unset the INSTALL_MASK and run "emerge -e world" to
> get the files installed.

That's not really the case, either.  It's certainly possible to add 
absolute-path-specified names to INSTALL_MASK, and I've done just that in 
the past, tho I'm not doing so ATM.

It's also worth noting the /etc/portage/package.env file and /etc/portage/
env/ subdirs as covered in the portage (5) manpage.  Either of these 
methods can be used to set package-specific stuff like INSTALL_MASK, if 
the user doesn't want to make it global.  And the env/category/pkg feature 
can even be used for such shell logic as...

CFLAGS=${CFLAGS/ -combine/}

... which I routinely depend on for a number of packages as -combine is in 
my global CFLAGS (but not CXXFLAGS).

It's thus possible to use either absolute paths in the global INSTALL_MASK 
settings, or package-specific setting via two different methods, to 
control the installation of specific files.  And the documentation is 
there, in the usual and customary place one would expect to find it on a 
*ix system, the manpages.

I honestly don't see how a USE flag helps.  Yeah, it rubs the user's nose 
in it a bit more directly, but the users that really care either already 
know or can find out pretty fast when they need to, how to address the 
problem on their own systems, and for those that don't, it's yet more USE 
flag noise to mask the important stuff.  Plus, any USE flag added to a 
package is yet another bit of package maintenance for the gentoo 
maintainer to keep up on.  I simply don't see how the limited benefit can 
be considered worth the hassle, when both as explained here and as 
documented, the control is already there for those that actually care 
about it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




  parent reply	other threads:[~2011-04-25  5:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-24 21:58 [gentoo-dev] rfc: logrotate and xinetd use flags William Hubbs
2011-04-25  2:23 ` Jeroen Roovers
2011-04-25  5:09 ` Duncan [this message]
2011-04-25  7:13 ` Alec Warner
2011-04-25  7:44 ` Michał Górny
2011-04-25 20:57   ` Jeroen Roovers
2011-04-25 21:03     ` Michał Górny
2011-04-25 15:39 ` Michał Górny
2011-04-25 15:39   ` Ciaran McCreesh

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=pan.2011.04.25.05.09.04@cox.net \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-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