Hi, I'd like to second Guido's request, and provide you the justification you requested.
Some extra background:
For those who use git-buildpackage, there is an on-by-default feature
that warns about uncommitted changes in the bulid tree at the start of a
build process (after running clean). This is really useful from a
packaging QA standpoint and helps keep the builds clean and repeatable.
The .pc directory will trigger this and fail the build. It would be
desirable to not have to disable this feature just because of this
directory, and at the same time not have to hack in some kind of
workaround for specifically this problem.
Point 1:
Ignoring this file in .gitignore would require making direct changes to
the upstream source, which while very simple does kinda defeat the
principle of using quilt in the first place (putting the change in a
quilt patch would not be effective in the context of unapply-patches).
Point 2:
When unapply-patches is specified in source/local-options, it does not
end up in the resulting source package. thus, a user unpacking the
generated source package could still have the normal behavior of the .pc
directory remaining and everything functioning as you would want it
according to your previous response. Removing the .pc dir when this
feature is in local-options would only affect those who were building
from the VCS, which is exactly the class of people who would like to see
this fixed :)
So, my suggestion is that either the behavior of unapply-patches is
changed to remove the .pc dir *when specified in local-options*, or that
a new option is introduced specifically for instructing dpkg-source to
not leave the directory around.
Between the two, I would have a strong preference for the former,
because it would allow me to avoid adding a versioned build-dep on
dpkg-dev (which would be a hassle for any package that might potentially
be backported/crossported).
sean
signature.asc
Description: This is a digitally signed message part
