[Pkg-rust-maintainers] Override file format for debcargo

[Vasudev Kamath]

Ximin Luo <infinity0 at debian.org> writes:

> Vasudev Kamath:
>> Vasudev Kamath <vasudev at copyninja.info> writes:
>>> # This section basically to update Source package related fields.
>>> [source]
>>> [..]
>>> [package."librust-clap-2-dev"]
>>> [..]
>> 
>> One additional field I can think of here is *depends* to add additional
>> dependencies. [..] In any case I've coded it into debcargo.
>> 
>
> These are all generally quite sensible.
>
> I think dependencies is a good addition, yes. Being flexible is good,
> and I can see that certain packages might have dependencies that
> aren't easily automatable. Of course we should try to automate as much
> as we can. But certain things might not be detectable via
> ${shlibs:Depends} such as when calling an external bin program, or
> linking to data files.
>
> We'd also need recommends, suggests, etc etc.

OK alright I can work on that part. And also I'm not sure If I really
implemented applying dependency override. Its in override and parsed but
need to check if its applied.

>
> The various possible options should be documented somewhere.

Currently I'm using README.md for documenting various options. May be we
can utilize rust documentation feature.

>
>>>
>>> # This section is for overriding copyright values.
>>> [..]
>> 
>
> Your toml syntax is OK for the main overrides file because (hopefully)
> only a few specific things need to be overridden.
>
> I think however for copyright files, this is not such a good idea.
> It's likely that maintainers will need to override most of the
> copyright file. So I don't think we should force them to learning a
> new syntax for it. The same goes for d/changelog.
>
> We should focus on making the common case easy - that of updating a
> package. So what I imagine is, we store in VCS the following tree:
>
> packageA/debian/debcargo.toml
> packageA/debian/copyright
> packageA/debian/changelog
> packageB/...
>
> When a user runs "debcargo package", they can optionally give it an
> overrides directory. Then we could:
>
> 1. apply debcargo.toml as an overrides file like you implemented already
> 2. then, use copyright and changelog *verbatim* from the overrides directory
> 3. then, append an entry onto the d/changelog

This sounds OK to me. Do you think its better if I could just drop
overriding copyright and changelog from override TOML file completely?.
It does not make sense to keep it if we go this way.

> 4. then, autogenerate a copyright file, and put it in d/copyright.debcargo
> 5. then, download the older version of d/copyright.debcargo from the older debian package (or even autogenerate it from the older crate)
> 6. then, diff the old and new d/copyright.debcargo, and put it in
> d/copyright.debcargo.diff for the maintainer to review

I would rather depend on licensecheck and feature used in CDBS package
to generate copyright_hints instead. Idea is to avoid re-inventing
wheel. Use copyright file already provided by maintainer and then run
licensecheck with newer copyright to provide copyright_hints file which
can then be committed to version to detect only new stuffs.

>
> The maintainer can then update d/copyright manually, update anything
> else, check it into VCS, and run "debcargo package" again. Because the
> current crate version is the same as what's in d/changelog, debcargo
> will know to skip steps (3-6).

May be if we utilize licensecheck then this part is not really needed I
guess.

>
> Does that makes sense, and does the workflow seem decently simple to
> you? If there's anything else, we can extend it to cover that too.

Sure yes. Please let me know what you think of my comments above.

Cheers,

--
Vasudev