<div dir="ltr"><div class="gmail_quote">On Tue, 3 Mar 2015 at 09:41 Luca Bruno <<a href="mailto:lucab@debian.org">lucab@debian.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another two notes on this topic:<br>
<br>
* Many Cargo.toml specify a == version for dependencies.<br>
  We could end up maintaining so many source packages in parallel, which<br>
  sounds painful. Is there an easy way to do so (preferably without going<br>
  every time through NEW)?<br></blockquote><div><br></div><div>Yeah, I don't know what expedited options are available to us here.  We can automate the recompilation/upload cycle easily enough, but I imagine the hard bits are similar to what other language collab teams go through with maintaining all the python-*, libperl-*, etc packages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* IIRC cargo has some freeze/package subcommand (can't find the exact name<br>
  now). Which fetches and bundles all dependencies.<br>
  As we are using static linking anyway, what about having each package manage<br>
  its dependency?<br></blockquote><div><br></div><div>Interesting.  This is effectively shipping source for all dependencies along with every package.  Sounds like it would work well enough, but we wouldn't have dependencies expressed in the Debian package graph - so we'd need some new tools to work out what to rebuild following a security fix, etc.</div><div><br></div><div>I guess ideally whatever we come up with should be a similar workflow for us to cargo freeze: get upstream, auto-pkg all missing dependencies somehow, upload packages.  The difference is whether that appears to the ftp-masters as a flood of packages in NEW, or a single new fat package with a bunch of separate upstream sources (possibly duplicated with other source packages) embedded within it.</div><div><br></div><div> - Gus</div></div></div>