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

[Sven Mueller]

Henrique de Moraes Holschuh wrote on 31/08/2005 18:37:

Just to make sure we keep talking about the same thing, Ondrej listed this:
>> We need to support two paths:
>>
>> 1. unpack vanilla upstream
>> 2. drop debian/ subdir inside
>> 3. debuild should create packages and diff with debian/ only changes
>>
>> 4. debclean should put tree in buildable state
>> 5. debuild should create packages and diff with debian/ only changes

and said:

>>1.-3. just makes life easier :-)
>
> Agreed. I am against 5 (total waste of resources on buildds), and I have
> very serious reservations against 4, since it would increase diff size.

In my opinion: (4) should mean: debclean puts tree in a state from which
debuild works again.

BTW: This is the current behaviour of the cyrus22 package.

> We can usually use cyrus upstream tarballs without modification, I have not
> had a problem with them during all the cyrus 2.1 years :-)  So if a broken
> one ever shows up, we special-case it.

Basically, I agree.

> We could make all this dependent on a DEB_DOITLIKETHIS variable or somesuch,
> with the default being 1-3 and 4,5 being developer-only land.  I am
> certainly not make a fuss over someone commiting stuff like that, as it does
> not bother anyone that doesn't need to use it :)

True. I just had a lot of trouble due to "debian/rules clean" removing
files "debian/rules binary" was unable to reproduce when I moved from
cyrus21 packages to cyrus22 packages. I definately want to avoid that in
the future. So for all that matters, we have the following choices in my
opinion:

1) Keep the current (modified) cyrus22 .orig.tar.gz and just move on.
2) as 1, but provide the get-orig-source target so do the modifications
   needed
3) Use the prestine upstream source in the same way cyrus21 did:
   remove modified files to minimize diff size and ignore the fact
   that "debian/rules binary; debian/rules clean" can't be repeated
   within the same source tree without unpacking the original source
   (dpkg-source -x) again.
4) Like 3, but make sure debian/rules clean leaves the tree in a state
   where debian/rules binary would produce the correct binaries

I'm in favour of (2) or (4). Actually I would say go for (2) for now and
switch to (4) with the next upstream release. In either case, I
volunteer to implement it.

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/6f2ea538/signature.pgp