[PlanetCCRMA] Re: Other repositories

[Axel Thimm]

--BouVgDkIlpb7X6Bk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 27, 2004 at 03:15:56PM -0700, Fernando Pablo Lopez-Lezcano wrot=
e:
> On Wed, 2004-05-26 at 19:15, Axel Thimm wrote:
> > spec files are at http://atrpms.net/dist/fc2/alsa-driver/. There isn't
> > anything special to 28, other than it being the 28th build (I don't
> > reset the build number when the version bumps).
>=20
> I see. Maybe you should (just a suggestion). Current practice (AFAIK) is
> to reset to one on new versions.=20

I had the specfiles retrieve their release tag from CVS some time ago,
and am currently switching to subversion. This will probably be the
same for Red Hat as soon as they get the CVS server automatically
tagging releases on the SCM release tag.

> > 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? :)
>=20
> 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? :) :) :)

> 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 :)

> I could also require >=3D 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. I am
confident that freshrpms/Matthias would also accept an authority on
alsa on PlanetCCRMA.

> 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.=20

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.

If you start working on a PlanetCCRMA 2.6 kernel, 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.
--=20
Axel.Thimm at ATrpms.net

--BouVgDkIlpb7X6Bk
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAtm3ZQBVS1GOamfERAmKbAJ9L81frPFVuPUuHOITrcEVuJRIdBQCfQpAY
/DHxbEff0AmJzpataOvLQOk=
=MZXG
-----END PGP SIGNATURE-----

--BouVgDkIlpb7X6Bk--