[Pkg-Cyrus-imapd-Debian-devel] .orig.tar.gz orig vs. repacked

[Sven Mueller]

Henrique de Moraes Holschuh wrote on 31/08/2005 16:26:
> On Tue, 30 Aug 2005, Sven Mueller wrote:
>
>>dpkg-buildpackage -b -tc
>>twice from within the same unpacked sources, which makes developing a
>
> Removing files properly (i.e. you recreate them when you need them in the
> proper places in debian/rules) will NOT break dpkg-buildpackage -b -tc...

Right. However, when I migrated your cyrus21 work to cyrus22, running
dpkg-buildpackage twice within the same tree (as created by dpkg-source
-x) didn't work.

>>lead to the same conclusion: A source package should be left in a
>>buildable state after "debian/rules clean". Simply removing modified
>>files defeats this under many circumstances.
>
> Well, that conclusion is incompatible with using separate build-trees (many,
> MANY packages do this, xorg comes to mind).  There are a lot of packages
> that cannot be even packaged in other ways (because they build a number of
> different versions of their programs using different build-trees).

When I said in a buildable state, I meant in the sense of being able to
run "debian/rules binary" successfully. I.e. if debian/rules is able to
reconstruct deleted files or trees, that is perfectly fine to me.

> I'd say that a Debian build-tree must be Debian-buildable after debian/rules
> clean, i.e. thorugh debian/rules.  Anything else simply does not match
> reality.

I certainly agree with that.

>>1) add a target create-tarball (or however it was called) to fetch the
>>   newest upstream tarball and repack it as we want it.
>
> That's doable, and there is a semi-standard target for it. I don't recall
> which, though.  We will have to hunt it down in the MLs.

get-orig-source, see
http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules

That section even says that though the target is optional, providing it
"is a good idea".

Note that the target doesn't necessarily need to modify the orig.tar.gz
file before packaging. However, I tend to say we could keep our current
orig.tar.gz as is and move to the full original upstream tarball with
the next upstream release.

>>2) clean up and modify the upstream tarball contents during build,
>>   reverting changes to non-auto-generated files in "debian/rules
>>   clean".
>
> Yuck.  Waste of resources for NO good reason whatsoever.  If someone wants to
> build the upstream source with all breackages, he can get the upstream
> tarball and use it.

I think we think along the same line here.

>>>Why do we need to have a cleaned up .orig.tar.gz?  It ends up causing us
>>>more work, since we have to take care of it anyway.
>>
>>True. That's why I want to get back to the pristine upstream tarball.
>
> So we do the cleanup in debian/rules where needed, then (this is what I do
> in EVERY package I maintain :-) learned it with ESR's fetchmail tarballs
> that would do very, very unpleasant things from time to time).  What I do
> not agree with is going to the kind of pain we will have to to restore the
> build *tree* to the fucked-up state after a build.

Na, I just want to make sure that after "debian/rules clean", the source
tree looks as close as possible to what "dpkg-source -x" unpacked. Or at
least as close as necessary so that "debian/rules binary" would work again.

cu,
sven

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-imapd-debian-devel/attachments/20050831/a8ffc9ab/signature.pgp