Adding Provides: strictdep-kernel[-flavour]-arch = kernelevr to kernels (was: Nameing guideline ...)

Nicolas Mailhot Nicolas.Mailhot at laPoste.net
Thu Dec 18 14:43:54 UTC 2003


Le jeu 18/12/2003 à 15:11, Axel Thimm a écrit :
> On Wed, Dec 17, 2003 at 04:59:53PM +0100, Nicolas Mailhot wrote:
> > Le mer 17/12/2003 à 15:51, Chris Ricker a écrit :
> > > On Wed, 17 Dec 2003, Nicolas Mailhot wrote:
> > > 
> > > > So make the SMP one require the UP.
> > > > Frankly SMP alsa users are the minority, they'd better have an UP kernel
> > > > as fallback, so they can live with two alsa modules without polluting
> > > > normal user systems.
> > > 
> > > Why? My SMP boxes don't have a UP kernel on them.
> > 
> > Well, better :
> > - SMP users shall have SMP and UP code
> > than :
> > - everyone shall have SMP and UP code
> > 
> > And anyway who is going to use 2.4 alsa on smp now ?
> 
> The naming guidelines should serve more than alsa on 2.4 up machines
> ;)
> 
> I had gone through various models and finaly arrived at the same
> solution as Fernando. It is the only maintainable way for supporting
> all the released kernels.

Well I'm not arguing against strict rules but forcing SMP and  UP in the
same package. Seems way to kludgy for me, when splitting in two packages
can be done easily.

As far as I'm concerned we should have module requires exact kernel for
which it was build, and if someone could add a gcc check somewhere this
probably be all to the better.

(with 2.6 if we can get the config used exported in /proc/config.gz I'm
all for requiring a config check at install time, even if it means being
unable to install modules for a not-live kernel. Mismatching modules and
kernel can be *nasty*)

Cheers,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031218/5e21d8c0/attachment.sig>


More information about the fedora-devel-list mailing list