[Slackbuilds-users] RFC: "driver" category for kernel modules/drivers

[David Spencer]

The usual answer to this question when it regularly crops up (e.g.
gis, fonts) is: does it matter if people can find what they are
looking for?

Let's supplement Ed's pool of evidence. What is a driver? In the
strict technical sense, drivers are kernel modules, and the SBo built
packages usually (== really should) append the kernel version to the
package version. eg.
nvidia-legacy96-kernel-96.43.23_3.10.17-x86_64-1_SBo

By that criterion, the drivers in the repo are

misc/klibc [false positive, but should this be libraries/?]
network/broadcom-sta
network/ndiswrapper-kernel
system/lirc
system/nvidia-kernel
system/nvidia-legacy*-kernel
system/spl-solaris
system/tp_smapi
system/vhba-module
system/virtualbox-kernel
system/virtualbox-kernel-addons
system/zfs-on-linux

We should really add in userspace components (audio/oss,
system/rng-tools, system/nvidia*-driver etc). They are all in system/
except the ones that have good excuses to be elsewhere (audio/ and
network/). That is quite a different list from Ed's -- which exposes
the limitations of tagging.

(Having spent time setting up catalogues of historical archives, I
know more than I want to know about the limitations of tagging.
Abstract tags like "driver" (or "rural") are worse than useless.
People looking for a Broadcom network driver should not be using
"driver" as a search term; people researching eighteenth century
agriculture should not be searching for "rural"; people looking for
terrorists should not be trying to grep the entire internet. In all
these cases the problem is the same -- false positives will swamp the
real positives. When inexperienced taggers are tagging, the only
solution is for the set of possible tags to be carefully curated.)

Database library shims may be "drivers" to the upstream libdbi
developers, and so in the case of libdbi-drivers SBo has to follow
their terminology, but functionally it is a plugin for a library, and
that's why it is filed right next to libdbi. The same argument could
be made for libva-intel-driver. If libva-intel-driver moves to system,
libva should logically move with it, and if libva moves, logically
libvdpau and maybe opencl and cuda should move too. If that feels
wrong, maybe nothing should move :-)

Then there's the printer stuff. Printers were a mess before the
Stallman incident, they are a mess now, and they will be a mess on the
day that the last tree on Earth is sacrificed. Moving SBo's printer
drivers might make us all feel a tiny bit better... temporarily...

So. Having spent half an hour looking, I personally don't really have
an opinion, except (1) if you want a Broadcom driver, don't search for
just "driver", because (2) not everything tagged "driver" is a driver,
and (3) not all the drivers are tagged "driver"; (4) if there is a
category problem with drivers, there is a similar but bigger problem
with fonts; (5) it is handy to keep interdependent packages in the
same category (haskell/ ruby/ perl/ python/); and (6) the migration to
gis/ needs be completed when the repo is updated for 14.2.

Ok, that's six opinions.  Sorry.
-D.