Proposed F19 Feature: systemd features

[Bill Nottingham]

Kay Sievers (kay at vrfy.org) said: 
> > Realistically, it's new textual files, replacing old textual files, which
> > are then compiled into a binary file. I'm not sure why there's the
> > intermediate step of a second textual format, but there is.
> 
> Because the original text file is a hack and a format specific to the
> PCI/USB IDs, and makes no sense at all for a generic hwdb.

pci:v00000010*
 ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc

It's not like that's that much more of a generic format. :)

> >> It could go into another package when things have settled down, but
> >> there will be lots of other data in the same database shipped by
> >> systemd itself, like keymaps, power settings whitelists, which we
> >> cannot really and should not move out to a generic package.
> >
> > ... which, again, is not something you want to be updating the main
> > systemd package all the time for.
> 
> Which, again, is not needed at all, as mentioned above. :)

Is it strictly needed? No.

Is it needlessly making the problem worse? Yes.

Either you're intending for the lifetime of your OS to be shipping systemd
updates that update the base data set, or you're intending to be shipping
updated data sets in a separate package. Given systemd's churn rate, the
first seems impractical, and if you're doing the second, why not split it
out to begin with? (Much like the preset files.)

Bill