Re: [gentoo-dev] RFC: alsa-0.9 ebuilds

[Tod M Neidt]

On Sun, 2002-02-03 at 03:54, Tod M Neidt wrote:
> On Sun, 2002-02-03 at 02:53, Tod M. Neidt wrote:
> > On Sun, 2002-02-03 at 01:39, Tod M Neidt wrote:
> > > On Sun, 2002-02-03 at 00:12, Arcady Genkin wrote:
> > > > I've modified the existing ebuilds for the latest 0.9 alsa.
> > > >
> > > > 1. My first question is about the version numbering of the portage.
> > > > Alsa's own version numbering doesn't fit very nicely into gentoo's
> > > > guidelines.  I translated 0.9.0b10 into 0.9.0_beta10, which worked
> > > > fine.  However, how do I deal with something like 0.9.0b10a?
> > > > 0.9.0_beta10a doesn't work, so I kept it simply at 0.9.10_beta10
> > >
> > > I would probably name it, -0.9.0a_beta10 (I think thats a legal portage
> > > version scheme).
> > >
> > Ok, I was wrong.  The trailing letter doesn't work in conjuction with
> > _beta (or _alpha for that matter). Doh, note to self, "Review Developer
> > HOTO."
> >
> > I guess I'll name it alsa-*-0.9.0.10a.ebuild, unless someone has a
> > better suggestion.
> >
> Ok, ok how about this
>
> alsa-driver-0.9.0_beta10.ebuild
> alsa-lib-0.9.0.1_beta10.ebuild
> alsa-util-0.9.0.1_beta10.ebuild
>
> The .1's will correspond to the "a" beta suffix of the tarball.  That
> way we can go to 0.9.0.2 and so on if they happend to release another
> beta10 version and the users will still know that it is a beta from the
> ebuild name. (I hope the release alsa-1.0 soon so this just goes away :)
>
> I will also try to throw together ebuilds for the alsa tools and OSS
> Compat library.
>
Hi!

I have commited upgraded alsa-0.9 ebuilds to portage using the naming
scheme above.  The lib and utils ebuilds have some version munging in
them to handle the vexing alphabetic suffix on the tarball version.
(It's not pretty, but it works and will disappear when 1.0 is released)

I have package masked them initially because additional testing should
be done (any brave volunteers?).  The reason is that the 0.9 version
doesn't install libasound.so.1 and just about everything directly or
indirectly linked to it previously will break.  For example, I had to
recompile gdk-pixbuf (what the hell does that have to do with sound?)
because it is linked to gnome-libs which is linked to libasound just to
get Gnome to startup after upgrading.  Fortunately, libasound.so.2
appears to be backwards compatible with libasound.so.1, so I added a
'dosym /usr/lib/libasound.so.2 /usr/lib/libasound.so.1' to the alsa-lib
ebuild.  This appears to work, and will allow users to upgrade to
alsa-0.9 without recompiling everything.  However, I have only tested
this with Gnome, and gnome apps plus xmms. Good news is that I'm
listening to my mp3's in xmms and also getting all the "beeps, boinks
and blips" out of the Gnome Destop.  If someone is adventurous, testing
with KDE would be appreciated.

Note: There is an "Easter egg" feature added to alsa-drivers from Arcady
Genkin.  If you know what sound card you require, you can set the
environmental variable ALSA_CARDS or pass it to ebuild (or emerge when
and if they are unmasked) and only that driver will be built.  For
example in my case, 'ALSA_CARDS=als4000 ebuild
alsa-driver-0.9.0_beta10.ebuild merge' will only build the driver for my
als4000 card.  You can also pass it a list of drivers you want built. 
Of course, the default is still to build all the drivers.

Regards,

tod