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

[Ximin Luo]

Vasudev Kamath:
> [..]
>>
>> 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.
> 

Ack, I'll remember to test this too.

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

I noticed this after I wrote my email, so I take my comment back :) Either way sounds good to me, but if you have two copies then it's more work to keep it up-to-date.

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

Yes, that's what I meant. If we override d/changelog and d/copyright we don't need to support it in the overrides.toml, so we can remove all of that code.

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

Using licensecheck sounds good to me. Though, you wrote some code in debcargo to do some specific copyright detection/guessing for rust git repos - it would be a shame to delete it, but I'm also not sure if it's appropriate to merge it into licensecheck because (a) it's in rust not perl and (b) it's only for rust git repos.

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

licensecheck is far from perfect so I think we have to assume a reasonable amount of manual maintenance will be required at least for some crates - the workflow I presented (diffing etc) is me trying to make a smooth process for this, automating away as much of the boring repetitive stuff as possible.

> [..] Please let me know what you think of my comments above.
> 

X

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