On Fri, 2005-08-19 at 00:16 +0200, Andreas Gruenbacher wrote:
> My example was not perfectly well chosen. The idea was to have provider
> prefixes like adaptec, nvidia, ati and similar, so an example out-of-line
> aic7xxx upgrade would be adaptec-aic7xxx-8.9.10-2.6.13_99_smp-3, etc.
I don't see it serving any purpose. I don't want to have a field that
people are trying to shoe-horning ugliness into. This just opens the
door to rpms with horrible provider prefixes, and rpms with %{name}:
InternationalBusinessMachinesJapanCOPYRIGHT2005ALLRIGHTSRESERVED-mwave-3.1415972-2.6.13_99_smp
... when all we really need is:
kernel-module-mwave
> > > The driver name, driver version, and kernel release ($KERNELRELEASE) are
> > > also stored differently in rpm tags: our build system likes to be able to
> > > freely assign the package release number, so we don't store extra
> > > information there. Rather, we put the driver version in the Name, and the
> > > kernel release in the Version:
> >
> > Hmm. Again, I don't want to overload %{name}. That's not what its there
> > for, imho.
>
> What makes %version or %release more appropriate for overloading? With the
> driver version as part of %version or %release, you can't easily offer
> packages for more than one version of a driver for the same kernel, and yet
> have working updates. I would be surprised if you didn't ever have this
> situation with RHEL.
Users won't expect to have the name be overloaded. Users want to search
for "kernel-module-foo", query the rpmdb for kernel-module-foo. Not to
mention the nightmare of tracking it in bugzilla, and generating massive
amounts of unnecessary SRPMs.
And we can certainly offer multiple packages.
kernel-module-foo-1.2-1.2.6.13_93smp (driver version 1.2, build 1)
kernel-module-foo-1.2-2.2.6.13_93smp (driver version 1.2, build 2)
kernel-moudle-foo-1.3-1.2.6.13_93smp (driver version 1.3, build 1)
~spot
--
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
