[PlanetCCRMA] Re: Other repositories

[Fernando Pablo Lopez-Lezcano]

> > > I'd like to create a situation, where PlanetCCRMA superseeds ATrpms in
> > > the choice of alsa bits (ATrpms needs alsa for the few users that
> > > don't want to mix repos and the ones using ATrpms' kernels). Would you
> > > bump the version up to above 28? For the next alsa-driver release I
> > > could use a 0-prefixed release tag to ensure PlanetCCRMA always
> > > superseeds. Is that a deal? :)
> > 
> > I was thinking on something like this myself for packages that I have to
> > "borrow" from other repositories. Definitely doable. But there are finer
> > details to work out. Like kernel modules for your kernels,
> 
> Do you suggest to build alsa kernel modules for ATrpms' kernels? :) :) :)

I don't think I can do that and mantain my sanity (or whatever is left
of it). 

> > compatibility between versions and so on and so forth. Another
> > detail is that I usually package cvs after the usual flurry of bug
> > reports after a release subsides (your users may not want to use
> > cvs).
> 
> Well, if you as PlanetCCRMA (aka audio/sound expert community with
> packaging skills) consider a sound module requires a cvs update, I
> would blindly accept this. The typical PlanetCCRMA user has much
> higher expectations on the sound/audio components than the ATrpms
> user, so if you manage to satisfy PlanetCCRMA consumers, ATrpms
> consumers will be more than happy :)

Maybe. I surely don't satisfy all my users all the time :-) I'm not even
sure if packaging cvs is the best option, but it has worked fine so far
(or so I think). 

> > I could also require >= in my planetccrma-core-* packages but then other
> > type of problem may happen. For example in my packages I currently
> > include the rc startp script alsasound, last I checked freshrpms did
> > not. So if for some reason freshrpms overrides my packages then the
> > startup script would dissapear...
> 
> That would be bad. Since we have now Red Hat entering the field, we
> should try to sync/adapt to whatever solution there exists. 

That's what Matthias was/is doing with his packages. That is, sound is
treated only as a module to be loaded on demand, not as am rc service
that can be started and stopped. 

As I strongly prefer to have it trated as a service then conflicts will
inevitably arise (I link it very much to be able to restart alsa when I
want to). I could separate the alsasound script in a separate package, I
think that would be reasonable. An added problem is that all the
configuration instructions will have to be rewritten for both cases :-) 

Realistically, treating it as a service won't really work on FC2 stock
configurations for the gnome panel (at least with the current version).
The "volume" applet is part of the panel by default and is now an alsa
application, of course. Stopping sound with the alsasound script has the
unfortunate side effect of killing the applet (because it has
/dev/snd/whatever open... now it should not have it open if you are not
changing the volume, right?... bug maybe?). 

> I am confident that freshrpms/Matthias would also accept an authority on
> alsa on PlanetCCRMA.

Not necessarily as I'm not currently using the same paradigm as RedHat
uses. 

> > Hmmm, difficult, I have to give this some more thought. I still think
> > (for now) I'd prefer my alsa packages to always be there unless
> > overriden explicitly. 
> 
> Me also, and I would love to see them for ATrpms' kernels, too :)
> 
> BTW I switched to the kernel-module-foo-<uname -r> names, for better
> or worse.

Aha! I did that a couple of weeks ago when I started working on the
2.6.x kernel for FC2... good...

> If you start working on a PlanetCCRMA 2.6 kernel, 

Too late, I've already started :-)

> do you think we can consolidate forces to have a common kernel? I would inject
> v4l2/i2c/lm_sensors and stuff like that that should not interfere with
> the usual PlanetCCRMA kernel patches.

Where would be those patches be? I don't want more patches :-) There are
now very few patches that are specific to Planet CCRMA. 

I'm currently building a version based on Arjan's 1.391 (I've gone
through at least 6 or 7 builds so far). Still having problems with
latency that I now think are related to xorg...

-- Fernando