FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-21-2011, 02:05 PM
Ulrich Mueller
 
Default On the use of bash-completion use flag

>>>>> 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
 
Old 06-23-2011, 08:41 AM
Gilles Dartiguelongue
 
Default On the use of bash-completion use flag

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
 
Old 06-24-2011, 07:07 AM
Michał Górny
 
Default On the use of bash-completion use flag

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
 
Old 06-24-2011, 07:26 AM
"Paweł Hajdan, Jr."
 
Default On the use of bash-completion use flag

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.
 
Old 06-24-2011, 10:37 AM
Ulrich Mueller
 
Default On the use of bash-completion use flag

>>>>> 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
 
Old 07-08-2011, 09:12 AM
Gilles Dartiguelongue
 
Default On the use of bash-completion use flag

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
 

Thread Tools




All times are GMT. The time now is 07:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org