<div dir="ltr"><br>
</div><div dir="ltr"><br>
</div><div dir="ltr"><br>
</div><div dir="ltr"><br>
</div><div dir="ltr">Sent from my Mi phoneOn 14-Jun-<a href="tel:201704">2017 04</a>:02, Josh Triplett <<a href="mailto:josh@joshtriplett.org">josh@joshtriplett.org</a>> wrote:<br>
</div><div dir="ltr"><br>
</div><div dir="ltr">On Tue, Jun 13, 2017 at 08:28:41PM +0530, Vasudev Kamath wrote:<br>
</div><div dir="ltr">> <br>
</div><div dir="ltr">> Hello All,<br>
</div><div dir="ltr">> <br>
</div><div dir="ltr">> I was working on debcargo on points mentioned by Ximin (infinity0). I've<br>
</div><div dir="ltr">> now completed refactoring debcargo. We were discussing next steps to<br>
</div><div dir="ltr">> package crates in IRC and Ximin brought up need for infrastructure for<br>
</div><div dir="ltr">> doing automated packaging of dependencies of rustc and cargo.<br>
</div><div dir="ltr"><br>
</div><div dir="ltr">Nice! Are those changes in the repository? I'll try to take a look soon.<br>
</div><div dir="ltr"><br>
</div><div dir="ltr">Yes in the branch feature/dep5-copyright. I started with introducing dep-5 copyright but ended up refactoring entire code base. Most of your logic remains same just moved into proper modules.<br>
</div><div dir="ltr"><br>
</div><div dir="ltr">> Here I'm quoting full text from IRC on our discussion.<br>
</div><div dir="ltr">> <br>
</div><div dir="ltr">> <br>
</div><div dir="ltr">> > [19:48:41]  i'd like this process to be as automatic as<br>
</div><div dir="ltr">> > possible b/c i don't want to maintain 20 separate rust packages<br>
</div><div dir="ltr">> <br>
</div><div dir="ltr">> > [20:01:00]  like, we'll have a script that automatically<br>
</div><div dir="ltr">> > runs debcargo on the 20 dependencies of rustc and cargo, rather than<br>
</div><div dir="ltr">> > me doing this manually <br>
</div><div dir="ltr">> > [20:01:09]  ah<br>
</div><div dir="ltr">> > [20:02:03]  if we need to make any patches to the<br>
</div><div dir="ltr">> > debcargo-generated packaging, we figure out some efficient way of<br>
</div><div dir="ltr">> > storing this under version control (.diff is the obvious choice but<br>
</div><div dir="ltr">> > it's not so nice to manually hand-edit these), and integrate this with<br>
</div><div dir="ltr">> > the script so that these patches also get applied when the script is<br>
</div><div dir="ltr">> > run, so we don't need to run patch(1) manually ourselves<br>
</div><div dir="ltr">> <br>
</div><div dir="ltr">> I also agree with Ximin as there are lot of small dependencies for<br>
</div><div dir="ltr">> crates and they in turn depend on another set of crates. So manually<br>
</div><div dir="ltr">> trying to package is a lot of task.<br>
</div><div dir="ltr">> <br>
</div><div dir="ltr">> Can we discuss on this and try to come to some sort of solution which<br>
</div><div dir="ltr">> reduces manual tasks.<br>
</div><div dir="ltr"><br>
</div><div dir="ltr">Increasingly, I think the right approach would be to have a single<br>
</div><div dir="ltr">repository which contains a list of crates we want to package (with easy<br>
</div><div dir="ltr">ways to update the list to include recursive dependencies), as well as<br>
</div><div dir="ltr">subdirectories for any of those crates that need any manual overrides of<br>
</div><div dir="ltr">the autogenerated packaging. Then we can run debcargo *once*, on the<br>
</div><div dir="ltr">top-level repo, and it'll pop out with any new source and binary<br>
</div><div dir="ltr">packages. Run it, upload any new ones, done.<br>
</div><div dir="ltr"><br>
</div><div dir="ltr">Yeah this sounds good. And I think it mostly handles all point brought up by Ximin<br>
</div><div dir="ltr"><br>
</div><div dir="ltr">-- <br>
</div><div dir="ltr">Vasudev</div>