[systemd-devel] [PATCH] hwdb: ship ids-update.pl & sdio.ids in the release tarballs.

[Dimitri John Ledkov]

On 17 March 2015 at 11:44, David Herrmann <dh.herrmann at gmail.com> wrote:
> Hi
>
> On Tue, Mar 17, 2015 at 12:27 PM, Dimitri John Ledkov
> <dimitri.j.ledkov at intel.com> wrote:
>> On 16 March 2015 at 23:15, Marcel Holtmann <marcel at holtmann.org> wrote:
>>> Hi Dimitri,
>>>
>>>> This makes it easier to apply stable branch patches on top of the
>>>> release tarball.
>>>> ---
>>>> Makefile.am | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Makefile.am b/Makefile.am
>>>> index 856accb..0ed35ac 100644
>>>> --- a/Makefile.am
>>>> +++ b/Makefile.am
>>>> @@ -3877,7 +3877,9 @@ dist_udevhwdb_DATA = \
>>>>       hwdb/70-touchpad.hwdb
>>>>
>>>> EXTRA_DIST += \
>>>> -     units/systemd-hwdb-update.service.in
>>>> +     units/systemd-hwdb-update.service.in \
>>>> +     hwdb/ids-update.pl \
>>>> +     hwdb/sdio.ids
>>>
>>> I do not think that these files belong in the tarball. Especially the sdio.ids is not something that should be in the tarball. If it is missing locally, a script can always download it rom systemd.git tree. That is where the source is for these and not the tarball.
>>>
>>> If you want to apply patches from git, then you can always tell git to exclude these files and it will happily apply the rest of the patch. So I do not see a good enough reason to do this.
>>
>> I should be able to regenerate generated copies of code from things
>> included in the tarball without network or git... I need this
>> precisely because stable patches are patching sdio.ids... which is (a)
>> missing (b) ids-update.pl is missing (c) the files that are generated
>> with a&b are not updated....
>
> (a) and (b) can be solved by telling 'patch' or 'git' to not apply
> hunks to those files.
>
> (c) sounds wrong to me. Whenever we change ids-update.pl and friends,
> we also run them and commit the results to -git. So either you apply
> the wrong patch (the ids-update.pl-path instead of the patch that
> commits the results), or your haven't been looking closely enough. I
> don't see why a distribution would be interested in fixes for
> ids-update.pl? It should be ignored and never marked for back-porting.
> Only if at the same run we also update the generated files, those
> should be picked up.

Looking at stable branch:

http://cgit.freedesktop.org/systemd/systemd-stable/log/hwdb?h=v219-stable

sdio.ids was changed in
http://cgit.freedesktop.org/systemd/systemd-stable/commit/hwdb?h=v219-stable&id=c10e229f8222b92117ba38045ddb3e4d7951244a

but updated in a later commit
http://cgit.freedesktop.org/systemd/systemd-stable/commit/hwdb?h=v219-stable&id=9ac622b00ca23f9d01e0ff0c944130be8dc3a0e9

So they do look up to date there.

usb.ids does not appear to be in the source tree.

To me this looks untidy, as preffered form of modification is not
shipped in full neither in git, nor in the tarball. And I do need to
modify them, the hwdb is too large and has too many things for my
targets thus I'm looking at how to patch them out in a maintainable
way.

Why not just commit ids-update.pl / sdio.ids and generate the .hwdb
files on $ make dist, or at autoreconf time?

-- 
Regards,

Dimitri.

Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.