Re: Standardizing NO_NETWORK and USE_SYSTEM_DEPS environment variables

--=-=-=
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable

Micha=B3 G=F3rny <[email protected]> writes:

> 1) NO_NETWORK -- if it's set to a non-empty value, it requests that
> programs don't access the (TCP/IP) network.

To me this sounds like an obviously good idea, and would consider using
both in my upstream and packaging work.

> 2) USE_SYSTEM_DEPS -- if it's set to a non-empty value, it requests that
> the build system does not use any vendored dependency for which it
> supports using a system version instead, and that it links to shared
> libraries whenever possible.
...
> For USE_SYSTEM_DEPS, the primary goal is to build against system
> dependencies.  For example, some upstreams either prefer using vendored
> dependencies or fallback to them when the system dependencies aren't
> found.  However, in Gentoo we really do want stuff to use system
> dependencies -- and if we miss to specify them appropriately, we'd
> rather see an error than an implicit fallback to a vendored dependency.
> So if USE_SYSTEM_DEPS is set, the build system should enable using
> system dependencies whenever supported, and disable all possible
> fallbacks to vendored dependencies.

This sounds really complicated, and speaking as an upstream that would
receive a request like this, my initial reaction would be that an
environment variable like that is a bad idea and that it is better to
handle it by the packager for each distribution.  Why?  In many of my
upstream packages, I have ./configure checks that inspects system
characteristics and changes behaviour of my code as appropriate.  I
believe this is the correct approach to handle system differences.  I
also believe it is not possible to adhear to a variable like that,
because it assumes there is one single ideal "system" version of
dependencies.  This isn't the case for almost anything.  Even trivial
functions like strverscmp() in low-level libc has had behavioural bugs
in them.  Should a USE_SYSTEM_DEPS cause the project to assume that
strverscmp() works correctly or not?  You can repeat this question for
even more trivial matters up to big things where there is no single
right answer at all, consider having to support multiple OpenSSL APIs
for example.  What OpenSSL version is a "system dependency"?  The only
reasonable response upstreams can do for this is to detect system
differences, and act accordingly.  Distributions who package these
packages usually just use the defaults, but if there is a bug for your
particular system (like strverscmp() or OpenSSL check returns
incorrectly), you have to patch things depending on how your environment
looks like.  Upstreams doesn't have the context knowledge you do to do
the right thing here.

/Simon

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmeSSfQUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJl/YgIBQkLehFUAAoJENc89jjFPAa+CboA
+wUa06RD5e5VTCxvSWtPS75Wq2qBeYGZnf0jvUMxa2n4AP4xkUeAPPnNuMsTm2fs
FCDIGaEM2Yn6Vb2huzzT1Fw/BLgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZf2IKwUJC3oQqgCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+GcYA/26YQY05bLtnXiIjTiAzrGQrRXxTHPA8Av7TDFHvIetWAP9s
HSoU8OfTwmTiEnGwLlsV7QJclZg3YNz/Ypcp9TqQBrg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJl/YgwBQkLehDGAAoJENc89jjF
PAa+phoA/jrDqIrl/55vUMBhIQv+TP635d2iCTEnyFmbUcP9+gh6APoDsXalVd2c
OGxQtSC+TF8PkZMn1TLkJKAjVxr+xx40AgAKCRBRcisI/kdFop4wAP0SZRGLxJdh
kigeUCSvA7xmZagZlhy0j9f8a/4jiOLVEAEA4zzOCaN8rf97ed6HmpJpvWwkAP7M
JfneWnVTy1kzlgY=
=Wm+w
-----END PGP SIGNATURE-----
--=-=-=--