Re: [H-source-users] [bug #63209] devuan GNU/Linux not on list of supported distributions

[bill-auger]

generally, it goes without saying that existing relations should
be preserved - the distro names and device VID/DIDs are the only
data represented canonically in the database - to delete an
existing distro or device ID, would normally orphan entries
which cross-reference that foreign table entity (ie: broken join
table entries) - systems which want to allow for that (eg:
deleting a registered nickname), usually will have special code
to default orphaned references to a generic stable entry (eg: an
'anonymous' user)

so yea, i think we all agree that only upcoming debian releases
are subject to debate - but i have been trying to convince
everyone that the distro name is not important data, but purely
informational - if a user of debian-42 wants to add an entry via
the web interface, but debian-42 is not an option, that person
will simply choose the newest option, or the generic unstable

this recent event in debian only reinforces the case for
diminishing the significance of distro names, in favor of the
data which actually determines whether or not "it works with
free software" - i dont think many people care which distro the
device was tested on - they want to know "does it work with free
software?"

if we did a better job at validating the inputs (eg:
whitelisting/canonicalizing kernel modules), the data would be
more reliable than now, even if submissions were accepted from
any arbitrary distro, libre or not - it is the obvious best
solution, but a significant extra workload to implement and
maintain

WRT debian specifically, i think that the risk of misleading data
will be high, and just as high for debian/devuan as for _any_
other distro then - it is more likely than not, that any given
computer _will_ have a non-free device attached (eg: wifi, GPU)
- now that most new debian systems will have the non-free repos
enabled, those devices will work (the form question "does it
work?" will be "yes", and lspci/lsusb will report their kernel
modules as "in use" (the user will have a perfectly valid
(though non-free) .ko filename for the "kernel module" field)