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