#592839 dpkg-source option to remove files on unpack: debian/source/remove-files

Package:
dpkg-dev
Source:
dpkg
Submitter:
Raphael Hertzog
Date:
2013-09-03 23:42:05 UTC
Severity:
wishlist
#592839#5
Date:
2010-08-13 07:46:46 UTC
From:
To:
Package: dpkg-dev
Version: 1.15.8
Severity: wishlist

As suggested by Ian on -devel (see attachment), it would be nice to have
a way to remove files during unpack of a source package to hide non-free
files from our users without stripping them from the original tarball.

I also prefer this approach over repacking upstream files so let's
implement this feature.

To be consistent with other features like debian/source/include-binaries
I suggest to use a file named debian/source/remove-files (and not a field
in .dsc) but if you have a better name, feel free to suggest it.

Cheers,
#592839#10
Date:
2010-08-13 10:27:51 UTC
From:
To:
Raphael Hertzog <hertzog@debian.org> writes:

How does that differ (legally, from ftp-masters perspective) from
running the clean target?

From the users side would it really be so bad if those extra files exist
initially after unpacking the source but get removed in debian/rules?

MfG
        Goswin
#592839#15
Date:
2010-08-13 10:27:51 UTC
From:
To:
Raphael Hertzog <hertzog@debian.org> writes:

How does that differ (legally, from ftp-masters perspective) from
running the clean target?

From the users side would it really be so bad if those extra files exist
initially after unpacking the source but get removed in debian/rules?

MfG
        Goswin
#592839#20
Date:
2010-08-13 16:58:07 UTC
From:
To:
Raphael Hertzog <hertzog@debian.org> writes:

I'm pretty sure ftp-master isn't going to allow source packages with
non-free content in the main archive regardless of whether that content is
hidden on unpack (I certainly wouldn't if I were them), so implementing
this is kind of pointless for Debian.
#592839#25
Date:
2010-08-13 17:01:34 UTC
From:
To:
What if the list of binary components was part of the watch file
instead; so that new upstream sources could be automatically stripped of
those non-free bits by uscan right after download.

Best wishes,
Mike
#592839#30
Date:
2010-08-13 17:04:14 UTC
From:
To:
Russ Allbery wrote:
Seconded.
#592839#35
Date:
2010-08-15 00:33:23 UTC
From:
To:
Another use-case might be to remove "convenience copies" of system
libraries.  Might be useful (e.g. for security reasons) to be able to
guarantee that this code isn't being accidentally used by a build (in a
way that can be easily checked by a script).

Cheers,

	David.
#592839#40
Date:
2010-08-16 18:59:16 UTC
From:
To:
This doesnt sound useful for non-free files, at least not if you want
your package end up in main/contrib, but for the useless source copies
many have, sure it will help there.
#592839#45
Date:
2010-08-16 18:59:16 UTC
From:
To:
This doesnt sound useful for non-free files, at least not if you want
your package end up in main/contrib, but for the useless source copies
many have, sure it will help there.
#592839#50
Date:
2010-08-18 08:29:26 UTC
From:
To:
David Claughton <dave@eclecticdave.com> writes:
debian/rules?

Legally that should be the same. And practically you would have the
useless files on the initial source unpack but they would be gone when
debian/rules is invoked the first time. dpkg-source -x could run the
clean target by default to make the files disapear directly.

MfG
        Goswin
#592839#55
Date:
2013-09-03 09:47:40 UTC
From:
To:
It is sometimes convenient to keep files deleted in the integration
branch of a version control system even if these files are dfsg free;
most recently I did this to facilitate cherry-picking patches from
upstream of an embedded library (yes, ick, I know).  There is no nice
way of representing this in a quilt series; one easily ends up with
enormous patches.  Currently I do some shenanigans like

         git diff --diff-filter=D --name-only >> debian/clean

This works, but the dependence on debhelper to unpack is unsatisfactory.

Cheers,

d
#592839#60
Date:
2013-09-03 18:45:33 UTC
From:
To:
Hi,

David Bremner wrote:

Please keep in mind that these emails appear in a crowded inbox, so
the subject line can be a good place to put valuable context.

I don't think I understand this particular use case --- why patch the
embedded library instead of just removing it? --- but David
Claughton's example of being able to simply and reliably remove an
embedded convenience copy of another package in a way that tools like
lintian can notice makes sense to me.

If someone writes a patch, I'll be happy to review it. ;-)

One can't rely on the clean target having been run before the initial
build anyway, no?

Lazily,
Jonathan
#592839#65
Date:
2013-09-03 23:27:23 UTC
From:
To:
Jonathan Nieder <jrnieder@gmail.com> writes:

The embedded library is actually a fork, with tiny but functionally
significant changes.

d
#592839#70
Date:
2013-09-03 23:39:15 UTC
From:
To:
David Bremner wrote:

I think we're veering off topic, but if you'd like help getting the
source package that provides the normal library to provide the
modified library as an extra binary package, I'd be happy to work on
that.

Thanks,
Jonathan