[Pkg-pascal-devel] FPC 2.6.4 is released.

[Abou Al Montacir]

On Thu, 2014-03-27 at 21:14 +0100, Paul Gevers wrote:
> On 27-03-14 20:45, Abou Al Montacir wrote:
> >>> Also removing many .o could reduce the size.
> >> I think this is the ONLY reason we have.
> > This a quite good reason.
> 
> Only if it is a lot, yes.
Re-packaging allows going from 54M to 49M, so I don't feel like this is huge (10%).

> > So I definitely think we are allowed to do this, otherwise dpkg-source
> > will detect untracked changes (date comment in Makefile) and abort
> > build.
> 
> No, if you remove the Makefiles in your clean target, then dpkg-source
> will not abort (it will give you the warning you mention below, but that
> is harmless and correct).
Anyway, it seems that those make files and .o files that are removed
during the clean target are the real cause of "git buildpackage" to
fail!

I have re-packaged again removing .o files and it worked perfectly. I've
pushed this for record, but of course it does not mean I'm pushing to
enforce my point of view. It is only to record something as working.

> >>> This avoids warnings about missing makefile after clean.
> 
> Sorry, I misunderstood this sentence the previous time.
> 
> >> The current clean does not work if a build is aborted halfway. So we
> >> need to fix it. I also don't understand what you mean, did you ever have
> >> a warning that the Makefile was missing?
> > 
> > Do you see?
> > dpkg-source: warning: ignoring deletion of file fpcsrc/rtl/palmos/m68k/libcrt.a
> > dpkg-source: warning: ignoring deletion of file fpcsrc/rtl/palmos/m68k/crt0.o
> > ...
> > We got the same think for make files.
> 
> But this is perfectly acceptable. That is what happens if you remove a
> file in clean that is in the tar ball. No problem at all.
I also think this is acceptable. But as you can see above, this is
preventing "git buildpackage" to work. As this is the way I want to
enforce as standard flow for this group. I'm a bit confused how to
proceed. For me "git buildpackage" is the easiest and the standard way
to go. But we are dealing about a 'dirty' upstream package. And
repackaging is the only way I see to workaround this.

I've also Tried push on upstream side to not package the make files, but
they argued that for newbees, this could be a real problem.

Of course, as upstream developer, I can add a debian centric tar.gz.
This is already done for dos, win with .zip sources ... But this is kind
of repackaging and is not contributing to transparence we want for our
packaging. For me, just adding a few lines in README.debian explaining
that we removed make files and that user can generate them simply by
executing "find * -name Makefile.fpc -exec ${FPCMAKE} -Tall -q '{}' ';'"
is enough.

Cheers,
Abou Al Montacir,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20140329/ad9d615b/attachment.sig>