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

[Ximin Luo]

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.

The various possible options should be documented somewhere.

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

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

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.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git