public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Chris Gianelloni <wolf31o2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Default Ebuild behaviour
Date: Tue, 31 Jan 2006 14:51:00 -0500	[thread overview]
Message-ID: <1138737060.14527.14.camel@cgianelloni.nuvox.net> (raw)
In-Reply-To: <20060131154702.11a027ad@snowdrop.home>

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

On Tue, 2006-01-31 at 15:47 +0000, Ciaran McCreesh wrote:
> Not really. For some packages, cron files must always be installed for
> proper operation. For some packages, cron files are strictly optional
> extras for features that many users will not want. For many it's
> somewhere in between. For packages in the first group, a USE flag is
> silly. For packages in the second group, not using a USE flag is silly.
> For the in-between cases, that's one of those areas where the ebuild
> maintainer has to make an educated decision.

Personally, I would prefer USE *not* be used for this.  As I understand
it, USE is for optional dependencies/support in a package.  The
logrotate USE is a good example of this not being the case.  The package
has logrotate support already, or the logrotate file's existence is not
tied in any way to what the package was compiled with (squid being the
obvious exemption here).

Basically, if the package *requires* something to function, such as a
cron script, then it should install it unconditionally.  If it does not,
then it shouldn't install it.  Having to change USE to get a stupid
cron/logrotate file is definitely not the best option.  Why not install
it to /usr/share/doc/$package as $package.logrotate and tell the user
about it instead?  The only case mentioned where the logrotate USE flag
changes functionality is squid, so it should keep the logrotate local
USE and everything else should drop it, then copy the logrotate files
into /usr/share/doc.  That way I don't have to --newuse and recompile a
package just to get a simple example logrotate file, things don't get
shoved into /etc without consent, and everybody is happy, right?  (Yeah
right... :P)

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2006-01-31 19:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-31 12:11 [gentoo-dev] Default Ebuild behaviour Benjamin Smee (strerror)
2006-01-31 12:31 ` Ciaran McCreesh
2006-01-31 14:03   ` Benjamin Smee (strerror)
2006-01-31 15:47     ` Ciaran McCreesh
2006-01-31 17:06       ` Benjamin Smee (strerror)
2006-01-31 17:24         ` Ciaran McCreesh
2006-01-31 20:15           ` Donnie Berkholz
2006-01-31 22:43             ` Henrik Brix Andersen
2006-01-31 22:53             ` Ciaran McCreesh
2006-01-31 23:03               ` Henrik Brix Andersen
2006-01-31 23:17                 ` Ciaran McCreesh
2006-02-01  0:02                   ` Henrik Brix Andersen
2006-01-31 23:14             ` Francesco Riosa
2006-02-01  1:32             ` Georgi Georgiev
2006-02-01 10:56             ` Rob Holland
2006-02-01 10:41           ` Benjamin Smee (strerror)
2006-01-31 19:51       ` Chris Gianelloni [this message]
2006-01-31 20:22         ` Alin Nastac
2006-02-01  8:59           ` Andreas Vinsander
2006-02-01  9:05             ` Andreas Vinsander

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=1138737060.14527.14.camel@cgianelloni.nuvox.net \
    --to=wolf31o2@gentoo.org \
    --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