[Pkg-pascal-devel] Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Paul Gevers]

Hi Abou,

On 11/16/17 11:40, Abou Al Montacir wrote:
>> 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.

Third option (the one I typically use): put the file(s) in debian/clean.
Anyways, the file(s) needs adding to debian/source/timestamps whether or
not we do this via patching.

>>  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)

Yes, but if I didn't make the patch (and/or it isn't documented in the
patch header) I may not know how to do it. In this case, it would
require me probably something like half an hour to figure it out.

>> 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.

Yes, and the timestamp goes into ppu files. That is a very annoying
issue in Debian where we want to build reproducible... See again
debian/source/timestamps. Which reminds me, some/all of these timestamps
should have been bumped with the new upstream release... I forgot about
that.

>> 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.

Too late now. We'll need to revert it in master *if* we need to upload
to unstable before your experimenting is over and be careful with the
merging afterwards. General note, please, don't ever change (git rebase)
the history of pushed changes, that is so confusing.

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20171117/7b7b386b/attachment.sig>