[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#786810: ITA: xl2tpd -- layer 2 tunneling protocol implementation



On Fri, May 13, 2016 at 08:42:56PM +0200, Vincent Zweije wrote:
> 
> It looks like things have got easier for me:
> * Upstream has incorporated the changes you had in quilt patches, removing the
>   need for quilt.
> * Upstream has removed the RFC text, removing the need for repacking.
> * Upstream has modified its debian directory to *almost* work, except that the
>   changelog file is bogus.
> 
> That last point doesn't matter really, as upstream's debian directory
> is discarded by dpkg-source -x anyway. Still, their changes to their
> debian directory can be taken over.
> 
The main thing with the debian/ directory is that git-buildpackage
expects there to be a "clean" upstream branch, usually called upstream
and with no Debian-specific changes in it, and another Debian branch,
usually called master and containing only Debian-specific packaging
changes.  I don't believe that upstream's repository enforces this
distinction.  That, along with the need to repack the source to remove
the non-free RFC text, pushed me toward simply importing the upstream
release tarballs (after they had been repacked) into my own repository
and working with the code that way.

> Am I correct in concluding that you were importing upstream releases
> whenever they came out, and not using git to merge their sources?
> 
That is correct.  I was using uscan to download the release tarball
(which got repacked by uscan) and then git-import-orig import it into my
repository.

> I'm considering stopping repacking upstream sources. Is there a concensus
> in Debian on whether it is better not to repack and be as close to
> upstream as possible, or to repack to get the debian directory out of
> there and save some space? Or is it just left up to the maintainer?
> 
I thin kthe consensus is to repack only when necessary.  If an upstream
tarball gets repacked, then it is no longer possible for a user to
compare the hash of the .orig.tar.gz to the hash of the corresponding
release tarball from upstream.  It is desirable to have the .orig.tar.gz
and upstream's release tarball be identical whenever possible.

Eliminating a problematic debian/ directory is certainly a valid reason
to repack.

> Do you have a close contact with upstream, or should I go through the
> regular channels? This in connection with forwarding the RC bug upstream.
> 
The only person from upstream with whom I had regular contact has moved
on a couple of years ago.  I would recommend just approaching them
through whatever normal public channels they have available.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Attachment: signature.asc
Description: Digital signature


Reply to: