Bug#796191: RFS: libharu/2.3.0+dfsg-1~exp1
Hi Johan
>Ok, I will check - some time since I last did this.
ack
>Should I do so before uploading to experimental?
nope, experimental will setup an automatic tracker for you, they might even
tell you to go for unstable whenever you like
>Looking at the policy I think it is better to document this in
>debian/copyright. I like to document why I remove files from the
>original source.
but you didn't remove them anymore, right?
anyway, let me know your solution :)
(looks e.g. to Files-Excluded copyright feature)
>Strictly speaking both are not necessary when you build the package
>the first time, however, when you rebuild a source package after
>building a binary package (or when using eg git-buildpackage) it will
>complain that these files have changed compared to the version in the
>tarball/repository.
I know this so well, the question is:
isn't something like
$ cat debian/clean
_configs.sed
include/hpdf_config.h
include/hpdf_version.h
more elegant that the patch itself?
the files might change, and the patch will be difficult/useless
to rebase
if dh_clean doesn't work as expected, dh_clean should be overrided, or made
smart enough to work, not override the patch phase instead.
this is my opinion about patching autogenerated files :)
(I had this trouble many times already :p )
cheers,
G.
Reply to: