| 1 |
On Sun, 2002-02-03 at 00:12, Arcady Genkin wrote: |
| 2 |
> I've modified the existing ebuilds for the latest 0.9 alsa. |
| 3 |
> |
| 4 |
> 1. My first question is about the version numbering of the portage. |
| 5 |
> Alsa's own version numbering doesn't fit very nicely into gentoo's |
| 6 |
> guidelines. I translated 0.9.0b10 into 0.9.0_beta10, which worked |
| 7 |
> fine. However, how do I deal with something like 0.9.0b10a? |
| 8 |
> 0.9.0_beta10a doesn't work, so I kept it simply at 0.9.10_beta10 |
| 9 |
|
| 10 |
I would probably name it, -0.9.0a_beta10 (I think thats a legal portage |
| 11 |
version scheme). |
| 12 |
|
| 13 |
Probably transform the P or PV variable so that at least the beta |
| 14 |
ebuilds are version independent so if subsequent alsa-0.9.0 betas are |
| 15 |
release we can just copy the ebuild over. |
| 16 |
|
| 17 |
For future reference the portage variable ${A} shouldn't be used in |
| 18 |
ebuilds anymore. As you have discovered, the existing alsa ebuilds are |
| 19 |
a little stale. |
| 20 |
. |
| 21 |
> |
| 22 |
> 2. The second question is regarding dependencies. alsa-lib is dependent |
| 23 |
> on alsa-driver, but in dependencies for current alsa-lib-0.5 only |
| 24 |
> "virtual/alsa" is specified. What is the rationale for that? I |
| 25 |
> thought that it's better to specify the alsa-driver package |
| 26 |
> explicitely, because alsa-lib needs exactly the same version of |
| 27 |
> alsa-driver with headers installed, or it won't build. |
| 28 |
|
| 29 |
I would agree with you here. The virtual alsa is for apps that depend |
| 30 |
on alsa. Would probably want to set the dependency like |
| 31 |
~media-sound/alsa-driver-0.9.0_beta10. The '~' will allow ebuild |
| 32 |
revisions, i.e. -r* to still count. |
| 33 |
> |
| 34 |
> 3. I provided a simple means for the users to build drivers for |
| 35 |
> only selected card(s) by setting an environment variable ALSA_CARDS. |
| 36 |
> By default (when the variable is not set), drivers for all cards are |
| 37 |
> built. Is this practice acceptable? (This is at the very top of the |
| 38 |
> ebuild for alsa-driver). |
| 39 |
|
| 40 |
sounds ok to me. does anyone else have an opinion? |
| 41 |
> 4. Finally, I'm not sure whether this version sould be masked or not. |
| 42 |
> I mean, it carries a beta designator, but IMO it's a more mature |
| 43 |
> software than the 0.5 branch. If I were to mask this version, how |
| 44 |
> would I go about it without having CVS access? |
| 45 |
|
| 46 |
If its better than 0.5 and it works, I don't think it should be masked. |
| 47 |
|
| 48 |
> I'd appreciate if somebody had a look at these ebuilds (there are |
| 49 |
> three of them: alsa-driver, alsa-lib, and alsa-utils) and commit them. |
| 50 |
> Since attaching files to bug reports doesn't work for me for some |
| 51 |
> reason, I've tarred them together and posted at the following URL: |
| 52 |
I have grabbed that bug, if I can still play my mp3's I'll commit them :) |
| 53 |
|
| 54 |
Thanks for the contribution. |
| 55 |
|
| 56 |
tod |
Archives