| 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 |
Archives