On Tue, Jan 29, 2013 at 9:06 PM, Bill Nottingham <notting@xxxxxxxxxx> wrote: > 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. 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
