Edgar Fuß <ef%math.uni-bonn.de@localhost> writes:
> I need a subpackage (sysutils/ups-nut-usb) to effectively overwrite a
> file (libexec/nut/nutdrv_qx) provided by the main package
> (sysutils/ups-nut). wiz@ suggested to use pkg_alternatives for this,
> but at a first glance, it doesn't seem to be the best solution.
> NUT (Network UPS Tools) is, in pkgsrc, divided into sysutils/ups-nut,
> which provides the serial UPS drivers, and
> sysutils/ups-nut-{usb,snmp}, which provide the USB and SNMP drivers.
>
> Most USB drivers are called foo_usb by upstream with a serial foo or
> foo_ser driver (e.g. there's bcmxcp and bcmxcp_usb, blazer_ser and
> blazer_usb), but the Q* meta-driver is simply nutdrv_qx and has USB
> support baked in or not.
>
> Presently, sysutils/ups-nut provides a serial-only nutdrv_qx, and
> sysutils/ups-nut-usb, provides, ehm, no Q* driver at all (it's lacking
> a few other drivers, but that's simple).
>
> I locally worked around this by making sysutils/ups-nut-usb install what should be nutdrv_qx as nutdrv_qx_usb, but that would force people to write
> driver nutdrv_qx_usb
> into their ups.conf file where they'd expect (from the docs) to use
> driver nutdrv_qx
> or their USB UPSen wouldn't connect.
>
> How to deal with this? Make sysutils/ups-nut install nutdrv_qx as
> nutdrv_qx_ser and link it to nutdrv_qx with sysutils/ups-nut/usb, in
> its INSTALL/DEINSTALL script, change the link to nutdrv_qx_usb and
> revert it back?
First, file a bug with upstream. This is not a reasonable way to do
things because it is very awkward to package. You might see what Debian
and FC packages do. But as I looked into this, I bet they just require
usb.
I would be inclined to patch ups-nut to omit the driver, have
ups-nut-usb install it has nutdrv_qx as people inspect, and if people
want to use it ia serial, they'll just have to install ups-nut-usb.
That feels only slightly awkward for them, and they can always get
upsteam to fix things if it bothers them :-)
I suspect that upstream's view is that the prevalence of USB is so high
that why is anybody bothering to have a package w/o USB.
Looking at the build files, it seems upstream has a notion of building
with usb support or not, and doesn't really have notion of a separate
install for usb drivers. So they'd say we are doing it wrong.
My ccache output from building ups-nut-usb just after ups-nut is
cache hit (direct) 5
cache hit (preprocessed) 91
cache miss 43
so it seems it is rebuilding all the non-usb stuff.
Sizewise, libusb1/libusb-compat is only 350K, and the USB drivers are
490K. ups-nut is 5.6M to start with.
Therefore, we could consider just requiring usb in ups-nut, and dropping
the ups-nut-usb package. That will make a few people with serial-only
UPS units have to have the libusb1 package installed. As a random
datapoint from someone who has several serial UPSes from the 90s, I have
one machine where libusb1 is installed anyway for something else and one
where I don't realize why it should be but it's there.
Are there platforms where libusb is not going to build, and we'd thus
deprive people of serial-only ups-nut? We could make it a default-on
option for such people (to turn off) if they turn out to exist.
Attachment:
signature.asc
Description: PGP signature