>>>>> On Tue, 21 Jun 2011, Nguyen Thai Ngoc Duy wrote:

>> --- Comment #2 from Gilles Dartiguelongue <eva@gentoo.org> 2011-06-21 09:35:59 UTC ---
>> Afaik, the bash-completion eclass adds the use flag only to make
>> sure the user has bash-completion and eselect packages installed.
>> This is imho overkill and it indeed meets the point that was made
>> on the ml that installing one file that doesn't in itself depends
>> on anything doesn't warrant a USE flag. Maybe the discussion should
>> be brought to dev ML to make the situation clearer for
>> bash-completion too.

> OK let's hear from the ML. Another good thing from bash-completion
> eclass is that it advertises bash-completion in pkg_postinst (though
> some packages miss this). If we're OK for dev-libs/glib not to use
> bash-completion use flag, what about the others, drop the use flag?

With the flag, some additional files are installed _and_ additional
dependencies like app-shells/bash-completion (which will pull in
further dependencies) are required. Looks like a perfect case for a
USE flag to me. For example, users of embedded systems may not want to
install such additional packages.

Ulrich

Le mardi 21 juin 2011 à 16:05 +0200, Ulrich Mueller a écrit :
> >>>>> On Tue, 21 Jun 2011, Nguyen Thai Ngoc Duy wrote:
>
> >> --- Comment #2 from Gilles Dartiguelongue <eva@gentoo.org> 2011-06-21 09:35:59 UTC ---
> >> Afaik, the bash-completion eclass adds the use flag only to make
> >> sure the user has bash-completion and eselect packages installed.
> >> This is imho overkill and it indeed meets the point that was made
> >> on the ml that installing one file that doesn't in itself depends
> >> on anything doesn't warrant a USE flag. Maybe the discussion should
> >> be brought to dev ML to make the situation clearer for
> >> bash-completion too.
>
> > OK let's hear from the ML. Another good thing from bash-completion
> > eclass is that it advertises bash-completion in pkg_postinst (though
> > some packages miss this). If we're OK for dev-libs/glib not to use
> > bash-completion use flag, what about the others, drop the use flag?
>
> With the flag, some additional files are installed _and_ additional
> dependencies like app-shells/bash-completion (which will pull in
> further dependencies) are required. Looks like a perfect case for a
> USE flag to me. For example, users of embedded systems may not want to
> install such additional packages.
>
> Ulrich
>

my point was the same that was made for systemd. The service files are
useless until you install systemd, yet the eclass doesn't pull systemd.

Hence my request for ml's opinion about why/how bash-completion is any
different ?

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

On Tue, 21 Jun 2011 16:05:59 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Tue, 21 Jun 2011, Nguyen Thai Ngoc Duy wrote:
>
> >> --- Comment #2 from Gilles Dartiguelongue <eva@gentoo.org>
> >> 2011-06-21 09:35:59 UTC --- Afaik, the bash-completion eclass adds
> >> the use flag only to make sure the user has bash-completion and
> >> eselect packages installed. This is imho overkill and it indeed
> >> meets the point that was made on the ml that installing one file
> >> that doesn't in itself depends on anything doesn't warrant a USE
> >> flag. Maybe the discussion should be brought to dev ML to make the
> >> situation clearer for bash-completion too.
>
> > OK let's hear from the ML. Another good thing from bash-completion
> > eclass is that it advertises bash-completion in pkg_postinst (though
> > some packages miss this). If we're OK for dev-libs/glib not to use
> > bash-completion use flag, what about the others, drop the use flag?
>
> With the flag, some additional files are installed _and_ additional
> dependencies like app-shells/bash-completion (which will pull in
> further dependencies) are required. Looks like a perfect case for a
> USE flag to me. For example, users of embedded systems may not want to
> install such additional packages.

For the additional dependency, I'd put it in some common ebuild (like
bash, or something without compiled binaries -- even better) and I'd
put the flag there.

There's no reason that a dozen of packages PDEPENDs on bash-completion.
If one decides not to use bash-completion any longer, I don't see a
reason to rebuild all those packages just to get rid of one PDEPEND
(and a single file).

--
Best regards,
Michał Górny

On 6/24/11 9:07 AM, Michał Górny wrote:
> For the additional dependency, I'd put it in some common ebuild (like
> bash, or something without compiled binaries -- even better) and I'd
> put the flag there.
>
> There's no reason that a dozen of packages PDEPENDs on bash-completion.
> If one decides not to use bash-completion any longer, I don't see a
> reason to rebuild all those packages just to get rid of one PDEPEND
> (and a single file).

Seconded. I'm in favor of installing bash completion files
unconditionally, and telling the user what to emerge (bash-completion)
to use them.

This is really very very similar to logrotate I think.

>>>>> On Fri, 24 Jun 2011, Michał Górny wrote:

> There's no reason that a dozen of packages PDEPENDs on
> bash-completion. If one decides not to use bash-completion any
> longer, I don't see a reason to rebuild all those packages just to
> get rid of one PDEPEND (and a single file).

The question is where to draw the line:

"There's no reason that a dozen of packages RDEPENDs on emacs. If one
decides not to use emacs any longer, I don't see a reason to rebuild
all those packages just to get rid of one RDEPEND (and a single
file)."

Same argument. Should packages install their emacs support files
(it's only one or two small files in most cases) unconditionally?

But seriously: I believe that most people would agree that logrotate
config files should be installed unconditionally, whereas in the case
of emacs they would disagree. bash-completion is somewhere inbetween.

Ulrich

Le vendredi 24 juin 2011 Ã* 12:37 +0200, Ulrich Mueller a écrit :
> >>>>> On Fri, 24 Jun 2011, Michał Górny wrote:
>
> > There's no reason that a dozen of packages PDEPENDs on
> > bash-completion. If one decides not to use bash-completion any
> > longer, I don't see a reason to rebuild all those packages just to
> > get rid of one PDEPEND (and a single file).
>
> The question is where to draw the line:
>
> "There's no reason that a dozen of packages RDEPENDs on emacs. If one
> decides not to use emacs any longer, I don't see a reason to rebuild
> all those packages just to get rid of one RDEPEND (and a single
> file)."
>
> Same argument. Should packages install their emacs support files
> (it's only one or two small files in most cases) unconditionally?
>
> But seriously: I believe that most people would agree that logrotate
> config files should be installed unconditionally, whereas in the case
> of emacs they would disagree. bash-completion is somewhere inbetween.
>
> Ulrich
>

Well I'd be in favor of installing emacs support files unconditionally
even though I don't use emacs and I'm not a fan of "wasted space". I
feel like we have enough means for people who care about space to get
rid of these.

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo