<br><br><div class="gmail_quote"><div dir="ltr">On Mon, 25 Jun 2018, 05:07 Josh Triplett <<a href="mailto:josh@joshtriplett.org">josh@joshtriplett.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Jun 24, 2018 at 07:01:00PM +0000, Ximin Luo wrote:<br>
> Josh Triplett:<br>
> > On Sun, Jun 24, 2018 at 02:01:20PM +0200, Paul van Tilburg wrote:<br>
> >> Hi,<br>
> >><br>
> >> I have noticed that patch metadata (i.e. the .pc dir) ends up in all<br>
> >> the -dev packages, even if there are no patches, and this is kind of<br>
> >> useless. Do you want me to file a bug report for that against<br>
> >> dh-cargo?<br>
> >><br>
> >> See for example this package listing (still in NEW):<br>
> >> <a href="https://ftp-master.debian.org/new/rust-lazy-static_1.0.1-1.html#binary-" rel="noreferrer" target="_blank">https://ftp-master.debian.org/new/rust-lazy-static_1.0.1-1.html#binary-</a><br>
> >> librust-lazy-static-dev-contents<br>
> >>  any built rust-*-dev deb on your system will have it.<br>
> > <br>
> > Argh. Checking upstream, it looks like the lazy_static crate does not<br>
> > include this directory, so it's an artifact of the Debian package build.<br>
> > <br>
> > It'd be trivial for dh-cargo to exclude the .pc directory, just as it<br>
> > currently excludes the debian directory and .git directory. It's<br>
> > theoretically possible that an upstream crate could include a .pc<br>
> > directory; it *shouldn't*, but it could. Hopefully that doesn't happen.<br>
> > <br>
> Cool so it is a bug then. I thought you might have done it on purpose, to indicate whether we did patch the original source code or not.<br>
<br>
No. Personally, I find it unfortunate that the 3.0 (quilt) source format<br>
creates .pc rather than something under debian/ .<br>
<br>
> The fix should be easy in dh-cargo. But we should also add debian/patches (if it exists) to the crate so that it's obvious from the binary package whether we patched it or not.<br>
<br>
Not a bad idea. Perhaps those should go in /usr/share/doc/$pkg/patches<br>
instead, since they primarily serve as documentation.  That will avoid<br>
including them in the registry's crate sources.<br></blockquote></div><div><br></div><div>Alternatively we could *not* include them in the binary package at all...</div><div><br></div><div>I don't think it's common for any other binary package to include a list of applied patches (and certainly not the patches themselves) except where the patches introduce some user visible change to the behaviour that deserves documentation.</div><div><br></div><div> - Gus</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>