Kay Sievers (kay@xxxxxxxx) 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. > > 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. > > 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. > 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. Bill -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
