On Friday 19 August 2005 01:00, Tom 'spot' Callaway wrote:
> 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.14
>15972-2.6.13_99_smp
>
> ... when all we really need is:
>
> kernel-module-mwave
Great, thanks for the thoughtful example. I was talking about a prefix from
the LANANA provider name registry,
http://lanana.org/lsbreg/providers/index.html, and I'm also aware that many
potential providers don't have an entry there, yet. Also see
http://lsbbook.gforge.freestandards.org/lanana.html about LSB's package
naming recommendations.
The two proposals, next to each other, and even for the same example, seem to
be:
Name: kernel-module-aic7xxx
Version: 6.2.36
Release: 1.2.6.13_rc6_1_smp
vs.
Name: adaptec-aic7xxx-6.2.36
Version: 2.6.13_rc6_1_smp
Release: 1
> > > > 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.
Putting aside FUD for a second, where do you see problems querying the rpm
database, or in Bugzilla? And why do you think the number of source rpms
would change at all?
> 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)
You can have multiple packets next to each other, but rpm --freshen (and other
tools using the same logic) won't work as expected anymore: you will always
end up with the most recent driver version. Sticking with the same driver
version by default will break.
-- Andreas.
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
