[Top][All Lists]

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

Re: libidn2 build requires network + wget

From: Simon Josefsson
Subject: Re: libidn2 build requires network + wget
Date: Wed, 28 Dec 2016 09:20:52 +0100
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)

Tim Ruehsen <address@hidden> writes:

> On Tuesday, December 27, 2016 1:43:36 PM CET Simon Josefsson wrote:
>> Hi Tim. There is a separate git repo for libidn2's debian packaging, I
>> prefer it that way. There are hundreds of linux distributions and it
>> doesn't scale to support them all in upstream git repo.
>> We can't download anything during build, that has to be changed. Debian
>> policies forbids that, and it is generally a bad idea. We can include the
>> files if the licenses permit.
> One more question... does Debian packaging with gbp rely on tarballs ?

I prefer to work through tarballs.  gbp can work with either style.
Some prefer a git-only work flow, I'm a dinasour who haven't made to
leap to an all-git workflow.

> If yes, we don't have to include the Unicode files into the git repo.
> If no, we have to add the Unicode files to the repo (absolutely no 
> downloading 
> allowed).
> Currently, I added the files to the (my) repo. But it feels so wrong...

There are a couple of ways to deal with this:

1) Add the upstream Unicode files to the git repository, and ship them
in the tarball.  Have code that parses them during build; alternatively,
pre-generate a parsed representation of the Unicode files during a
maintainer build, and let the parsed representation be used during
tarball builds.

2) Don't add Unicode files to git, but have a maintainer rule (or maybe
even bootstrap.conf rule) to download them.  Then 1.

I can't think of other approaches, but maybe there are more.

I dislike downloading of files (people are not always online, and being
stuck on an airplane for 10 hours without the proper external files is
painful), so I prefer to put the files in git actually.

Another aspect of this is to give the user full reproducible source code
-- if the Unicode text files aren't included in the tarball, the user
receiving the tarball cannot modify things.  This is against the spirit
of free software in my mind.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]