1 |
On Sat, 28 Oct 2006, Meino Christian Cramer wrote: |
2 |
|
3 |
> Hi, |
4 |
> |
5 |
> I do an |
6 |
> |
7 |
> eix-sync && emerge --pretend --tree --verbose --update --deep world |
8 |
> |
9 |
> on a regular basis. |
10 |
> |
11 |
> Each time the alsa-headers are offered for update. |
12 |
> |
13 |
> If alsa-headers 1.0.13 are installed, alsa-headers 1.0.12 are offered |
14 |
> for update. |
15 |
> |
16 |
> If alsa-headers 1.0.12 are installed, alsa-headers 1.0.13 are offered |
17 |
> for update. |
18 |
> |
19 |
> Seems to be an endless story. |
20 |
|
21 |
I think what's going on is that alsa-headers, alsa-lib, and alsa-driver |
22 |
have a sort of incorrect set of dependancies between them. AFAICT, |
23 |
alsa-driver shouldn't depend on alsa-headers at all, because it seems to |
24 |
be fine to build ALSA userspace against a newer version of the headers |
25 |
than your kernel actually supports (which happens automatically and |
26 |
silently if you're not using alsa-driver; the kernel source has an older |
27 |
version of ALSA than is the default version of alsa-headers, and no |
28 |
dependancy on it). |
29 |
|
30 |
In any case, alsa-lib and alsa-driver don't have dependancies between |
31 |
them, but each depends on having a matching verison of the headers, and |
32 |
only alsa-lib permits a newer version of the headers, and alsa-driver is |
33 |
currently behind, and emerge doesn't back-propagate dependancy |
34 |
information, but nothing bad actually seems to happen. |
35 |
|
36 |
-Daniel |
37 |
*This .sig left intentionally blank* |
38 |
-- |
39 |
gentoo-user@g.o mailing list |