OpenLiteSpeed Build Script Violating Debian Upstream Guide
Hello,
In Debian Upstream guide (https://wiki.debian.org/UpstreamGuide):
You should never assume that Internet access is available during building. Debian guarantees that every binary package can be built from the available source packages for licensing and security reasons.
Do not assume your VCS tools (e.g. Git) nor your VCS repository are available during the build.
Debian's Policy requires that Debian packages follow the Filesystem Hierarchy Standard for file locations. Debian packages are not installed into /usr/local. Thus Debian config files are found in /etc and manual pages in /usr/share/man. If your program normally installs to a different location please be sure to provide a mechanism to change the locations without patching the source. Use of environment variables for this purpose is recommended.
Avoid dependencies on unreleased versions (such as VCS snapshots)
Avoid dependencies on the patches applied in specific distributions or your own patches
If you need to patch a dependency please try to get your patch officially accepted by the dependency authors and document this process: When has this patch been sent to which email list or which issue tracker (with url)
If your software depends on other libraries, then Debian also needs to make sure that your software compiles and works with the version of these libraries available in Debian. Debian may compile your software against a different version of some library than you do.
Recently, I'm looking at build script (build.sh) from OpenLiteSpeed
source tarball. Upstream said that invoking build.sh to build OLS is
recommended way.
But I found that the build script violate Debian Upstream Guide, if we
package OLS by calling the build script from `debian/rules`:
1. The script builds OLS using specific version of CMake (3.14.5) and Go
(1.6), though it did mention installing cmake as build dependency from
apt. The script downloads both build tools and install them to
`/usr/local` (which Debian packages never do).
2. OLS depend on Git snapshot version of some third-party libraries
(`lsquic`, BoringSSL, and OLS third-party repo). Running `./configure`
also clone BoringSSL Git repo and patch it with OLS upstream changes
against specific commit in `master` branch, though I don't see the
anything in configure script that do the clone (perhaps at `configure.in`?)
3. `chmod 777 /tmp/shm ./install.sh` (seriously dangerous!)
4. The build script installs OLS to `/usr/local`.
If OLS will be packaged, should we use shipped `./build.sh` with flaws
above?
Bagas
--
An old man doll... just what I always wanted! - Clara
Reply to: