On Tue, Jan 29, 2013 at 9:06 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Kay Sievers (kay(a)vrfy.org) said:
> The hwdb is drop-in directory based, which means:
> - additionally installed data overwrites shipped data
> - stuff with the same file name in /etc/ disables stuff in /usr/lib/
>
> Users can just install update packages, or add their own files, which
> will not conflict with the default shipped data.
That's really not what we need, though - we have standing requests
in That Other OS for regular updates of the hardware database as used
by the tools, and having to spin systemd for this is way overkill.
Sure, create an RPM with non-conflicting files that are in /etc, or
sort numerically *after* the default files.
> > 1) Duplicates the data.
> > 1a) Will the two databases be kept in sync? How will that happen?
>
> No. In the long run the old textual files will no longer be used. It
> was a really bad idea from the start to parse several megabytes of
> ever-growing text files for every query submitted; it was showing up
> as CPU spikes in all sort of profiles. That model of implementing
> low-level operating system tools should just not be continued in the
> future. The systemd hwdb data can be queried almost for free.
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.
> > 2) Breaks the hwdata-vs-code separation that was created
earlier.
> > What were the reasons of the separation, and why are they no longer
> > applicable now?
>
> It's just not needed because of the /usr/lib/ etc/ and drop-in
> directory overwrite logic, that works for all other default vs.
> custom/update settings.
That method implies the administrator wants to do the update without
touching the code - what we have now is the *distributor* wants to
do the update without touching the code. And for that case, packaging
it seperately is simpler.
Sure, there can be am any update packages as one wants, it will all
work without any conflict with the original files.
> 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. :)
Kay