Pierre Pronchery <khorben%defora.org@localhost> writes: > On 07/23/15 14:47, Greg Troxel wrote: >> Pierre Pronchery <khorben%defora.org@localhost> writes: >>> On 07/23/15 07:23, David Holland wrote: >> Generally, we declare each variable to be user-settable in mk.conf >> or pkg-settable in Makefile, and never both. See the FETCH_USING >> flamage... > > Good point; I do think here it really makes sense to support both > though, just like in NetBSD's base system. And even then, packages > could set "PKGSRC_USE_SSP?=yes" and then the global setting would take > precedence always if set explicitly. That's exactly what we don't do. Basically, either a package sets things that are necessary, or a user sets choices. Now, if there's a reason why a package *has* to use SSP, or can't use it, then that would need to be noted. But it should be a different variable. An example might be something like MAKE_JOBS_SAFE, where a user sets MAKE_JOBS and packages with MAKE_JOBS_SAFE=no skip using it. So we might want SSP_SAFE=no to omit ssp on some packages, similar to MAKE_JOBS_SAFE and packages that don't do DESTDIR. I don't see why it's reasonable for a package to enable ssp if the user has not asked for it globally. I am confident that we can figure out something reasonable for any reasonable use case, though. >> I wonder if PKGSRC_USE_SSP should provoke an error if used with a >> compiler that doesn't support it, rather than silently failing. >> Or perhaps a warning; an error seems too much. But overall I think >> I agree with how you handled it. > > My personal opinion is that it should trigger an error, and certainly > not silently ignore it. It may not be the most practical answer for > our users - but certainly the most secure. I suspect it is mostly academic whether PKGSRC_USE_SSP=yes results in an error or a warning on os/cpu/compiler combinations that don't have support. I lean to a warning, because the notion that someone will turn it on without understanding that they might not get it seems a stretch. > 1. introducing the feature (disabled by default) You've committed this, so this is project. > 2a. adventurous people/projects (EdgeBSD...) enable it by default and > report/fix failures Sure, that's fine, or someone could turn it on individually, or do a bulk build with it. In your experience so far, do problems show up at build time, or do programs just not work, or ? > 2b. support gets added for more platforms > 3. enabling by default on NetBSD/gcc (possibly also clang), possibly > partially (like for base) To get to this, we probably need a SSP_SAFE=no define for individual packages. And confidence that we aren't causing undetected/unknown breakage. > 4. fail if enabled but not supported for the current platform That really doesn't seem useful. Let's defer this until after it's the default for NetBSD/gcc.
Attachment:
pgpBo799E8z82.pgp
Description: PGP signature