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 |
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 |
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 |
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. |
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 |
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 |
| All times are GMT. The time now is 09:47 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.