Proposed F19 Feature: systemd features

[Kay Sievers]

On Tue, Jan 29, 2013 at 9:06 PM, Bill Nottingham <notting at redhat.com> wrote:
> Kay Sievers (kay at 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