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

Re: Re: Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide

On 2020-03-07 15:47 +0700, Bagas Sanjaya wrote:
> > Packages must be self-contained, using only their contents and the Debian
> > repo during the build process. There are multiple technical and
> > non-technical reasons for this requirement, including knowing that the
> > package is DFSG-compliant and being able to always rebuild the package.
> But I found that `configure` script shipped with the OLS sources also invoke
> `git-clone`
> BoringSSL instead of relying on yet-to-be-packaged Debian package, though

So you need to package boringSSL before uploading this
package. Including this local patch assuming that it is necessary -
and in the process try to get that patch upstreamed in which case you
will be able to drop it.

Separately packaging build-dependencies is good policy, although it's
not an absolute requirement (unlike the network download). You could
ship a copy of the patched boringSSL as part of the openlightspeed

But check how many other debian packages actually use boringSSL. There
may be several packages in the same boat. (e.g when I packaged
something that had an embedded copy of libsquish it turned out that 6
other packages were also shipping an embedded or patched embedded
version, and it was fairly straightforward (with a bit of help from
upstream) to incorporate all the various patches into one libsquish
which then all those packages could just depend on. This is the right
way to do things, but it does of course take more time and work then
just stuffing yet another embedded 3rd party library into the source.

Ideally upstreams would be doing this work, but many leave it to
distros to tidy up their mess (and incorporate their laziness into
build systems which just adds more bodging to undo).

Principal hats:  Linaro, Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature

Reply to: