1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Mike Auty wrote: |
5 |
> Zac Medico wrote: |
6 |
> | Honestly I don't care what the existing scheme is. |
7 |
> |
8 |
> Fair enough, I don't maintain the code or have to deal with the |
9 |
> complaints. It seems a waste to abandon an existing scheme though. |
10 |
|
11 |
The "scheme" is pretty worthless in my eyes. The RESTRICT variable |
12 |
is quite useful for general purpose boolean flags so I see no reason |
13 |
not to use it as such. |
14 |
|
15 |
> Particularly since RESTRICT is an odd name for random boolean flags. |
16 |
> Something like OPTIONS would be better, but it that can't be |
17 |
> added/changed quickly. Is there an urgent pressing need for this? |
18 |
> |
19 |
> | primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS. |
20 |
> |
21 |
> | Looking at the above list I say it's fair game to put just about any |
22 |
> | boolean flag in RESTRICT. |
23 |
> |
24 |
> To me, almost every item in that list has "not", "disable", "restrict" |
25 |
> or some other negative in it, which lets it fit into a restriction. |
26 |
> Primaryuri is the only one that looks out of place. |
27 |
|
28 |
Again, such "schemes" are pretty worthless to me. But then, to have |
29 |
a RESTRICT=live setting for ebuilds would be quite useful. |
30 |
|
31 |
> You did sound up for a name change though, and if nothing else please do |
32 |
> change it. Our new users/developers that don't know RESTRICT is seen as |
33 |
> a general purpose options flag will not find it intuitive and will |
34 |
> definitely wonder what RESTRICT="live" means. Not everybody knows the |
35 |
> ebuild format intimately, and allowing people to easily pick up what's |
36 |
> going on is important... |
37 |
|
38 |
I chose "live" because I think it's easy for people to associate it |
39 |
with "live ebuilds", which I believe is a common term used to refer |
40 |
to ebuild that download live sources in src_unpack. What's in a name |
41 |
though? I'll gladly use whatever name satisfies the most people. |
42 |
|
43 |
> | That requires an EAPI bump, which also means that it can't be used |
44 |
> | in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we |
45 |
> | can use it right now in any ebuild. |
46 |
> |
47 |
> It is simpler, and as I say if there's an urgent need then go for it, |
48 |
> but to me it feels like it's bolting on functionality into any space |
49 |
> it'll go. Given that some time was spent changing all the "noblah" |
50 |
> flags to "blah" to fit the RESTRICT name, it's a little disappointing to |
51 |
> consider shoving extra flags in it now it all makes sense. |
52 |
|
53 |
Well, RESTRICT=live makes perfect sense to me and I see it as a |
54 |
legitimate use of an existing ebuild variable that's already used |
55 |
for lots of other legitimate purposes. |
56 |
|
57 |
> This is a relatively minor point. In the long run, if people don't like |
58 |
> it, it'll get QA bugged/ironed out, if they do it'll stay, you just |
59 |
> asked for thoughts... 5:) |
60 |
> |
61 |
> Mike 5:) |
62 |
|
63 |
Thanks for you input. It just seems to me that you're putting some |
64 |
artificial limitations on the RESTRICT variable while I see it as a |
65 |
more generically useful tool to accomplish a variety of useful purposes. |
66 |
|
67 |
Zac |
68 |
-----BEGIN PGP SIGNATURE----- |
69 |
Version: GnuPG v2.0.9 (GNU/Linux) |
70 |
|
71 |
iEYEARECAAYFAkiU4QEACgkQ/ejvha5XGaOwygCfSVU2FPS9Y83JD4X/nTu5BTW+ |
72 |
6RIAoLsEUDuEQKNkC7B2aPKCokMyETHv |
73 |
=bxM5 |
74 |
-----END PGP SIGNATURE----- |