Joey Hess <[email protected]> writes:
> Goswin von Brederlow wrote:
>> Didn't know the name for _darcs. Would it be possible to get a list from
>> dpkg?
>
> @Dpkg::Source::Package::tar_ignore_default_pattern is
> a list in dpkg, but it has a lot of other junk in it
> including things like *.o that dh_clean needs to clean.
Maybe dpkg maintainers could be convinced to split this into 2
variables. One for other junk and one for VCSes.
>> > Another approach could be to only delete known autom4te files
>> > from autom4te.cache (output.? , requests, traces.?) , and empty
>> > autom4te.cache directories.
>>
>> That would work for .hg. Don't know about the other VCSes.
>>
>> ls .hg/store/data/upstream/src/pmi/smpd/autom4te.cache
>> output.0.i requests.i traces.0.i
>>
>> But not for quilt as it creates .pc/<patch name>/<path>/<file>. But it
>> might be ok to require there are no stupid files in the patch series.
>>
>> As a sidenode would -X.pc/ skip that dir?
>
> Yes. Exporting DH_ALWAYS_EXCLUDE=.hg:.pc could also be used in your
> build environemnt. That variable also deals with problems like .hg
> directories accidentially getting copied into the binary by over-broad
> make install rules.
>
> --
> see shy jo
Excluding .pc in the source is OK as that is something of the source
packaging. But putting .hg there feels really wrong. What if I decide to
migrate to $OTHER_RCS_KEEPING_PATHS? Suddenly it would blow up on
dh_clean.
I also noticed that mvapich2 has a README.orig that actualy is a valid
file. Would it be possible to get dh_clean to be less clean? I can
delete *~ or *.o files myself if needed but I can't get files back that
dh_clean deleted. Maybe an option that would limit dh_clean to the
debian directory + debian/clean file?
MfG
Goswin
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
