[Pkg-rust-maintainers] Patch metadata in packages

[Josh Triplett]

On Tue, Jun 26, 2018 at 07:22:22PM +1000, Angus Lees wrote:
> On Mon, 25 Jun 2018, 05:07 Josh Triplett <josh at joshtriplett.org> wrote:
> 
> > On Sun, Jun 24, 2018 at 07:01:00PM +0000, Ximin Luo wrote:
> > > Josh Triplett:
> > > > On Sun, Jun 24, 2018 at 02:01:20PM +0200, Paul van Tilburg wrote:
> > > >> Hi,
> > > >>
> > > >> I have noticed that patch metadata (i.e. the .pc dir) ends up in all
> > > >> the -dev packages, even if there are no patches, and this is kind of
> > > >> useless. Do you want me to file a bug report for that against
> > > >> dh-cargo?
> > > >>
> > > >> See for example this package listing (still in NEW):
> > > >>
> > https://ftp-master.debian.org/new/rust-lazy-static_1.0.1-1.html#binary-
> > > >> librust-lazy-static-dev-contents
> > > >>  any built rust-*-dev deb on your system will have it.
> > > >
> > > > Argh. Checking upstream, it looks like the lazy_static crate does not
> > > > include this directory, so it's an artifact of the Debian package
> > build.
> > > >
> > > > It'd be trivial for dh-cargo to exclude the .pc directory, just as it
> > > > currently excludes the debian directory and .git directory. It's
> > > > theoretically possible that an upstream crate could include a .pc
> > > > directory; it *shouldn't*, but it could. Hopefully that doesn't happen.
> > > >
> > > 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.
> >
> > No. Personally, I find it unfortunate that the 3.0 (quilt) source format
> > creates .pc rather than something under debian/ .
> >
> > > 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.
> >
> > Not a bad idea. Perhaps those should go in /usr/share/doc/$pkg/patches
> > instead, since they primarily serve as documentation.  That will avoid
> > including them in the registry's crate sources.
> >
> 
> Alternatively we could *not* include them in the binary package at all...
> 
> 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.

We certainly don't *have* to do so, but considering that the binary
package contain the source code, including the patches doesn't seem
completely outlandish.