1 |
Alan McKinnon <alan.mckinnon <at> gmail.com> writes: |
2 |
|
3 |
> |
4 |
> On Thursday 27 March 2008, Michael Schmarck wrote: |
5 |
> > > The question now is why were the alsa, oss and other drivers |
6 |
> > > removed from the -base ebuild? |
7 |
> > |
8 |
> > Because they belong to the meta package, I suppose. The real |
9 |
> > question rather is, why was rb not updated to depend on -meta. |
10 |
> > I filed https://bugs.gentoo.org/show_bug.cgi?id=214852 for that. |
11 |
> |
12 |
> Good luck with getting a dev to agree to that. I wouldn't, and don't |
13 |
> know a single case in portage where an ebuild DEPENDS on a -meta ebuild |
14 |
> (possible -metas DEPENDING on subordinate -metas excepted) |
15 |
|
16 |
In that case, rb should depend on gst-plugins-base, but that's |
17 |
also not what them devs want. It rather seems, that they prefer |
18 |
that users have a non-functional system - which I find a quite |
19 |
strange attitude. But that's just me, I guess. |
20 |
|
21 |
> -meta packages are designed to be manually added to world by users who |
22 |
> wish an easy way to emerge everything. |
23 |
|
24 |
Fine, but did you actually have a look at the gst-plugins-meta |
25 |
package? It does *NOT* add everything. It is *NOT* at all like |
26 |
the kde-meta package. The gst-plugins-meta package only adds |
27 |
everything, if all the USE flags are set. Again, that's very |
28 |
much different from the kde-meta package - for it to be the |
29 |
same, the kde-meta would need to have, let's say, a "ppp" |
30 |
flag with which a user could control if ppp stuff (kppp for |
31 |
example) get's installed. But there's no such flag. |
32 |
|
33 |
> It's not described in policy |
34 |
> anywhere I have ever seen, the actual usage in practise tells you the |
35 |
> intended usage. |
36 |
|
37 |
The actual usage of other meta packages (again, I'm thinking |
38 |
abut kde-meta and also gnome-base/gnome here) differs *completely* |
39 |
from the usage of the gst-plugins-meta package. So I don't |
40 |
see, how you can compare different things here. |
41 |
|
42 |
> Go back and read bug 159470 again, especially comments 3 and 4. |
43 |
|
44 |
I don't quite understand that. Nobody is proposing, that rb should |
45 |
now grow an "alsa" USE flag. I'm also not saying that gst-plugins-base |
46 |
should re-grow the alsa USE flag. |
47 |
|
48 |
> The |
49 |
> dependencies you propose cause circular dependency loops |
50 |
|
51 |
Why's that? |
52 |
|
53 |
rb should depend on gst-plugins-meta which should depend on |
54 |
gst-plugins-alsa (if the USE flag is set so). |
55 |
|
56 |
> and |
57 |
> recompilation of packages that depend on the USE flags when they |
58 |
> change, even when the resulting files installed are EXACTLY the same as |
59 |
> the ones replaced. |
60 |
|
61 |
Care to expand on that? |
62 |
|
63 |
> This is the reason why the USE flags were removed |
64 |
> from the ebuild, |
65 |
|
66 |
That's fine. |
67 |
|
68 |
> to save you from the horror that is circular deps. |
69 |
|
70 |
Could you cook up a testcase to show that? |
71 |
|
72 |
> > > I recall something similar with another sound |
73 |
> > > app a while ago, the reason is that it could be used as a networked |
74 |
> > > sound delivery server and there's no good reason to require the |
75 |
> > > user to have sound driver support on the local machine. I suspect |
76 |
> > > your bug will be closed WONTFIX, with luck the dev will justify |
77 |
> > > their reasoning. |
78 |
> > |
79 |
> > If not, I'll reopen it. |
80 |
> |
81 |
> And Jakob will probably just close it. |
82 |
|
83 |
Then I'll reopen it. |
84 |
|
85 |
> He's brutal about that, and it's |
86 |
> his job. |
87 |
|
88 |
Dunno. But let's not discuss Jakub. |
89 |
|
90 |
> The problem you are trying to solve would be much better |
91 |
> served with a request for an ELOG to be emitted by rhythmbox alerting |
92 |
> to user to the need to install gst-plugins-whatever. |
93 |
|
94 |
I don't think so. |
95 |
|
96 |
> There's a damn good reason why rhythmbox does does depend on -meta. |
97 |
|
98 |
I suppose you mean "does not depend on -meta", right? |
99 |
|
100 |
> That |
101 |
> will never happen, so you should get over it. Bug 159470 explains why |
102 |
> it's not a good idea to depend on -base either, so now you get to issue |
103 |
> one more emerge by yourself. |
104 |
|
105 |
Actually, it doesn't. Comment #3 from Jakub doesn't apply. I totally |
106 |
agree with Jakub, that it might have been a bad idea to have something |
107 |
like |
108 |
|
109 |
mad? ( =media-plugins/gst-plugins-mad-0.10* ) |
110 |
|
111 |
in the totem ebuild. That sucks. Nobody wants that back. |
112 |
|
113 |
I seem to be missing something - what happens, if rb would |
114 |
depend on gst-plugins-meta? Suppose USE=alsa is set. Then if |
115 |
"emerge rhythmbox" would be done, gst-plugins-meta and |
116 |
gst-plugins-alsa would be emerged. Then the user thinks that |
117 |
dvb is a good idea and adds "dvb" to his make.conf file. |
118 |
If he'd recompile gst-plugins-meta, he'd also get gst-plugins-dvb |
119 |
installed. Would rb then need to be recompiled, in the point |
120 |
of view of emerge? |
121 |
|
122 |
Michael |
123 |
|
124 |
-- |
125 |
gentoo-user@l.g.o mailing list |