Hi Paul, On Wed, 2017-11-15 at 21:01 +0100, Paul Gevers wrote: > I am perfectly fine with you experimenting in experimental. > > I have a question regarding the patch, as you change generated *.inc > files, can't you generate those in the rules file instead of in the > patch? That's a very good question and I've asked myself why not regenerate the .inc file? The issue is that if we do then we end with a possible source change that is not carried in a patch and this does not please to dpkg-source (or some other dpkg-* tools I don't remember well anymore). So either we strip this file from original tar and force regenerating it or we patch it. I'm open to both and know how to regenerate this file. > My experience is that if upstream isn't going to carry the patch > it is hard to update the patch for files like for that every new > upstream release. Yes this is obvious, but updating the patch can be as simple as: apply the patch to real source file and then regenerate inc file and then update the patch (kind of quilt commit) > Also, I am not sure if we aren't already rebuilding > all generated *.inc files in our current build process. I have stripped > major blocks for our patches in the past, because they were totally > unneeded as the file was (or could be) regenerated. We are rebuilding some of them.I think many of them are automatically regenerated by upstream make files. > Paul > > PS: I would have appreciated it when you would have committed this on a > separate (experimental) branch. Sorry I didn't think about it. we can cherry-pick to experimental and then push -f to master~, but seems our git config refuse forced update.Do you have a clue other than git revert? otherwise it is also fine. -- Cheers, Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
