[Pkg-rust-maintainers] debcargo and dh-cargo ready for production use; sponsor request

[Ximin Luo]

Josh Triplett:
> [..]
> 
> For the .orig.tar.gz, I could just compare it to the .crate file and
> only error out if it differs.
> 
> Overwriting the actual source directory seems sufficiently dangerous
> (since you might have edited it) that I think it makes sense to require
> the user to delete or move aside the source directory first.  I could
> add a message saying to remove it if you want to regenerate it, though.
> 

Yeah, that would be fine - something that the user could copy and paste back into their shell to run, for convenience.

> Or, alternatively, I could have an option to write the new source
> directory with a .debcargo suffix or similar, which would make it easy
> to diff and merge in.  And I do like the idea of generating it into a
> dedicated git branch, too.
> 

For easy merging you'd need 3 directories - the edited tree, the original unedited autogenerated tree, and the newer autogenerated tree. So I think working directly on a git repo would be better than trying to "emulate" it awkwardly with multiple directories.

> [..]
> 
> As mentioned on IRC, we often don't have enough information to fill out
> DEP-5, because many crates (intentionally) don't include copyright
> notices, just license notices, and DEP-5 makes the "Copyright:" field
> mandatory.  I don't think it makes sense to use an
> almost-but-not-quite-DEP-5 format, because any tools expecting a
> machine-readable DEP-5 would fail to parse that format; better to look
> obviously not machine-readable.  If you'd like to see these copyright
> files use DEP-5, I'd suggest proposing a revision to DEP-5 to make the
> "Copyright:" field optional, for the case when no copyright notices
> exist upstream, which would allow us to generate a DEP-5-formatted
> copyright file for every crate.  In that case, I'd happily implement
> DEP-5 generation.
> 

In the cases where the crates don't self-identify the authorship, you can just default this to "Copyright: <year> <crate-name> authors". This is fine, I've done this in several packages before, and I haven't had my packages rejected by the FTP masters for that yet. It is more for information about authorship, rather than being a formal legal copyright notice. That is already contained (or not) in the rest of the upstream package, which we wouldn't be removing.

Anyway, even if it was not fine, I don't think it makes sense to let the fraction of packages that don't have this information, affect the ability to generate DEP-5 for the other crates. I can write the patch myself if you don't want to, I really do think this is better for Debian in the long run. Everyone is used to this format now, our eyes are trained to read this quickly.

Yes the Copyright: field probably should be optional for those anonymous projects, but it takes a lot of effort to make minor amendments like this to policy. There's lots of things in Debian that we do "by convention" that would ideally be Debian Policy, it's something you get used to. In fact there are many other annoyances of DEP-5 that I also have an interest in fixing, so if you care about it I would be up for submitting a format-1.1 proposal at some point. For now, please let's just stop reading too much into the "mandatory" part.

>>> If we can't successfully manage that, then as another alternative that I
>>> think I'd prefer, I'd like to make debcargo parse one or more input
>>> configuration files that specify tweaks for various crate packages.
>>> Temporary description overrides, additional dependencies, --bin and
>>> --bin-name values, dependency version overrides, etc.  That way, in the
>>> spirit of "don't check generated files into version control", the entire
>>> auto-generated Debian packaging can stay *out* of version control, and
>>> we can just check in the configuration files that control the
>>> automation.  We could then maintain a single repository with the
>>> half-dozen configuration files needed across a hundred crates, rev them
>>> as needed, and run some kind of "debcargo --recursive" to generate all
>>> the new or updated source packages.  (Those configuration files would
>>> then shrink or disappear as we find ways to upstream those tweaks.)
>>>
>>
>> I can see where you're going with this. It's a good idea, but I don't think this will work well for all packages. We should be *prepared* for something like the git workflow I described, and work in-tree directly on the generated package.
>>
>> There's lots of things one might want to do for potential rust software, that I don't think would fit well into your single-repo approach. For example:
>>
>> - multi-language software that contains cargo crates and other things
> 
> Many of those won't be able to use the majority of debcargo, and may not
> have uploaded their Rust bits to crates.io.  They also wouldn't work
> with the current dh-cargo.  So, I think we'll have to look at the first
> couple of these and figure out how to handle them.
> 
> [..]
> 
> Not at all; for those cases, I'd just add a directory that provides a
> debian/ overlay for a package.  Then you could provide debhelper
> configuration files, maintainer scripts (such as for alternatives), or
> anything else you want.
> 

OK. For these cases, I think that the git model I outlined earlier, would be easier to work with, than running debcargo to merge two directories together for every build attempt. It would still be easy to see the diffs, and update new versions.

>> [..]
> 
> I certainly don't want to force every package into that model.  I do
> want to try that model first, and only go the other route when we find
> something that doesn't fit.
> 

Understood, that's sensible.

X

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