1 |
On Tue, 21 Jun 2011 16:05:59 +0200 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
|
4 |
> >>>>> On Tue, 21 Jun 2011, Nguyen Thai Ngoc Duy wrote: |
5 |
> |
6 |
> >> --- Comment #2 from Gilles Dartiguelongue <eva@g.o> |
7 |
> >> 2011-06-21 09:35:59 UTC --- Afaik, the bash-completion eclass adds |
8 |
> >> the use flag only to make sure the user has bash-completion and |
9 |
> >> eselect packages installed. This is imho overkill and it indeed |
10 |
> >> meets the point that was made on the ml that installing one file |
11 |
> >> that doesn't in itself depends on anything doesn't warrant a USE |
12 |
> >> flag. Maybe the discussion should be brought to dev ML to make the |
13 |
> >> situation clearer for bash-completion too. |
14 |
> |
15 |
> > OK let's hear from the ML. Another good thing from bash-completion |
16 |
> > eclass is that it advertises bash-completion in pkg_postinst (though |
17 |
> > some packages miss this). If we're OK for dev-libs/glib not to use |
18 |
> > bash-completion use flag, what about the others, drop the use flag? |
19 |
> |
20 |
> With the flag, some additional files are installed _and_ additional |
21 |
> dependencies like app-shells/bash-completion (which will pull in |
22 |
> further dependencies) are required. Looks like a perfect case for a |
23 |
> USE flag to me. For example, users of embedded systems may not want to |
24 |
> install such additional packages. |
25 |
|
26 |
For the additional dependency, I'd put it in some common ebuild (like |
27 |
bash, or something without compiled binaries -- even better) and I'd |
28 |
put the flag there. |
29 |
|
30 |
There's no reason that a dozen of packages PDEPENDs on bash-completion. |
31 |
If one decides not to use bash-completion any longer, I don't see a |
32 |
reason to rebuild all those packages just to get rid of one PDEPEND |
33 |
(and a single file). |
34 |
|
35 |
-- |
36 |
Best regards, |
37 |
Michał Górny |