Gentoo Logo
Gentoo Spaceship

Installation:
Gentoo Handbook
Installation Docs

Documentation:
Home
Listing
About Gentoo
Philosophy
Social Contract

Resources:
Bug Tracker
Developer List
Discussion Forums
Gentoo BitTorrents
Gentoo Linux Enhancement Proposals
IRC Channels
Mailing Lists
Mirrors
Name and Logo Guidelines
Online Package Database
Security Announcements
Staffing Needs
Supporting Vendors
View our CVS

Graphics:
Logos and themes
Icons
ScreenShots

Miscellaneous Resources:
Gentoo Linux Store
Gentoo-hosted projects
IBM dW/Intel article archive




List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Mike Auty <ikelos@g.o>
Subject: Re: [RFC] New RESTRICT=live value for identification of live ebuilds?
Date: Sat, 02 Aug 2008 13:14:16 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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.

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...

| 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.

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:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiUT5cACgkQu7rWomwgFXqqdACfadwat4gS8/O4mX1zwcI+0VeU
XawAnjbJa2LXHiK1VMN7ZBf9ICNK+dtl
=572l
-----END PGP SIGNATURE-----


Replies:
Re: [RFC] New RESTRICT=live value for identification of live ebuilds?
-- Zac Medico
References:
[RFC] New RESTRICT=live value for identification of live ebuilds?
-- Zac Medico
Re: [RFC] New RESTRICT=live value for identification of live ebuilds?
-- Mike Auty
Re: [RFC] New RESTRICT=live value for identification of live ebuilds?
-- Zac Medico
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [RFC] New RESTRICT=live value for identification of live ebuilds?
Next by thread:
Re: [RFC] New RESTRICT=live value for identification of live ebuilds?
Previous by date:
Re: [RFC] New RESTRICT=live value for identification of live ebuilds?
Next by date:
Re: Gentoo Council Reminder for August 7


Updated Jun 17, 2009

Donate to support our development efforts.

Gentoo Centric Hosting: vr.org

VR Hosted

Tek Alchemy

Tek Alchemy

SevenL.net

SevenL.net

php|architect

php|architect

Copyright 2001-2007 Gentoo Foundation, Inc. Questions, Comments? Email www@gentoo.org.