| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 01/28/2014 06:45 PM, Martin Vaeth wrote: |
| 5 |
> hasufell <hasufell@g.o> wrote: |
| 6 |
>> |
| 7 |
>> Many defaults gentoo sets do not have anything to do with |
| 8 |
>> default codepaths upstream has tested. |
| 9 |
> |
| 10 |
> I disagree: The USE-enabling in ebuilds usually follows upstream. |
| 11 |
> IIRC there was even a policy for gentoo developers which strongly |
| 12 |
> suggested this. |
| 13 |
> |
| 14 |
|
| 15 |
I don't know of any and I strongly disagree with that concept. |
| 16 |
|
| 17 |
>> As above, our defaults are not necessarily following upstream |
| 18 |
>> recommendations/defaults. Apache alone should make you think |
| 19 |
>> about that claim. |
| 20 |
> |
| 21 |
> I never installed apache. However, especially for packages for |
| 22 |
> which the choice of algorithms has to be selected (USE-flags |
| 23 |
> thread, jit) or of protocols/interfaces (openssl or gnutls, neon or |
| 24 |
> other, sqlite or mysql, openvpn[lzo], qtgui[exceptions], mesa, |
| 25 |
> freetype, wine), the installation of tools (utils, examples, tk, |
| 26 |
> perl, python) or extensions (tls-heartbeat, introspection, X, |
| 27 |
> readline) the defaults usually follow the upstream default or |
| 28 |
> recommendation unless there is a severe reason not to. |
| 29 |
> |
| 30 |
|
| 31 |
No, they don't necessarily. There is no consistency about this. It's |
| 32 |
up to the maintainer to decide "what most users will want". You want |
| 33 |
upstream defaults, others want different things. The decision is made |
| 34 |
individually. And profiles totally mess up that concept anyway. |
| 35 |
|
| 36 |
What I was trying to say is: if you allow useflag combinations that |
| 37 |
break the package (both in terms of build, runtime or _unexpectedly_ |
| 38 |
missing features) or break reverse dependencies in those same ways, |
| 39 |
then it's a bug, a missing REQUIRED_USE constraint, a missing elog or |
| 40 |
whatever. |
| 41 |
|
| 42 |
The whole line of argumentation does not work out anyway, imo. |
| 43 |
Thinking that the defaults from e.g. "./configure --help" are what a) |
| 44 |
developers have tested most thoroughly and b) users of other distros |
| 45 |
like debian, ubuntu etc run... is simply an assumption. Debian rather |
| 46 |
goes for enabling whatever they can enable. |
| 47 |
|
| 48 |
Besides that... I run stable arch. And when I have a package that has |
| 49 |
severely broken runtime behavior with many useflags disabled (except |
| 50 |
for the features I expect to be disabled), then something went |
| 51 |
horribly wrong during stabilization. |
| 52 |
|
| 53 |
If we support disabling all useflags on package level (and we do), |
| 54 |
then we support disabling all on global level as well. All |
| 55 |
_unexpected_ breakage that occurs due to that are ebuild bugs that |
| 56 |
have incorrect dependencies or missing REQUIRED_USE constraints. |
| 57 |
|
| 58 |
Defaults are just a usability thing, nothing more. |
| 59 |
-----BEGIN PGP SIGNATURE----- |
| 60 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 61 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 62 |
|
| 63 |
iQEcBAEBAgAGBQJS5/H3AAoJEFpvPKfnPDWzGXEH/Aw68GvxkA98GoGfpYeD5jAB |
| 64 |
TEc6BE7BXX+SjToZZd2LGvyo0gpzocTwYf0Y2OMkVvlrft1a4LJVPX1pHK8NSPdv |
| 65 |
DIl7r+AosUcddBrSI45VuCC53sy66XxUDrsKnuXu1Qm9FlfIHhYTNcfxQM1v4UIx |
| 66 |
/IP3X+MzH+kklPnYqzHDwxY+lpS1JB3lCPbYvKoJLvk22s+F9ZMg2zdserWRnSRB |
| 67 |
EYKrw7ZbnornP71K7dQykQe0fh9f6d/s1fA56fvQ968Pfa1QIF/7eSd2270GF9Vq |
| 68 |
5KTWATp8rThfo9O526+A4bwgceDFe04Ksbf6p1oOjxe6Hn4MIo020YFhVl7HQNg= |
| 69 |
=NMPh |
| 70 |
-----END PGP SIGNATURE----- |
Archives