Proposed F19 Feature: systemd features

[Kay Sievers]

On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham <notting at redhat.com> wrote:
> 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 is entirely generic. It can carry arbitrary numbers of freely named
key/value pairs basically unlimited in their size. Is extensible, uses
flexible and extensible string matches like modaliases for kernel
modules. Nothing you would find in the PCI/USB IDs hack.

So what do you criticize here?

>> >> 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.

Worse? If we want an update package, it can drop the files in the same
directory the default files are, and they will be used instead.

Oh, and there are more copies of the PCI+USB IDs files in individual
packages already, just run:
  find /usr -name pci.ids
Maybe we should care about them first. :)

> Either you're intending for the lifetime of your OS to be shipping systemd
> updates that update the base data set,

I don't intend to ship update packages in the context of systemd, we
can just update the data in the package like we add patches for other
fixes, in case we need an update. In the end PCI+USB IDs are just
pretty boring names for humans, not used in the system itself. What
makes them so special? It really sounds more like cosmetic care, than
a real technical need to update these more often than we will need to
update systemd anyway.

> or you're intending to be shipping
> updated data sets in a separate package.

We can just do that, but still could ship the default data in the main package.

> Given systemd's churn rate, the
> first seems impractical, and if you're doing the second

Hmm, check how often hwdata was updated, vs. systemd was updated :)
  http://pkgs.fedoraproject.org/cgit/hwdata.git/tree/hwdata.spec#n40
  http://pkgs.fedoraproject.org/cgit/systemd.git/tree/systemd.spec#n730

> why not split it out to begin with? (Much like the preset files.)

Because preset files are for spins, and not generally useful static
data. They should be provided by the people doing a spin, but all
spins run on the same hardware. :)

And because we are not there yet, with introducing rather fragile
inter-package dependencies; things should have settled down before we
do this. It's all still under development.

And because a major part of the data the hwdb will carry in the future
will be the equivalent of udev rules, and should not be shipped by a
different package, because it it might carry specifics needed for a
certain functionality, just like the udev rules do today.

If we want to artificially declare the PCI+USB IDs different from the
rest of the growing hwdb data, and split that into a different package
and the rest not; sure, we can do that when things have stabilized,
but so far I'm not really sure if that will give is a significant
advantage, considering that updates just can be installed along with
the default data.

Thanks,
Kay