From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1N5ylb-0006ED-Gd for garchives@archives.gentoo.org; Thu, 05 Nov 2009 09:36:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CC447E0942; Thu, 5 Nov 2009 09:36:29 +0000 (UTC) Received: from mail-yw0-f191.google.com (mail-yw0-f191.google.com [209.85.211.191]) by pigeon.gentoo.org (Postfix) with ESMTP id A8DE3E0942 for ; Thu, 5 Nov 2009 09:36:29 +0000 (UTC) Received: by ywh29 with SMTP id 29so7063408ywh.32 for ; Thu, 05 Nov 2009 01:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=LMMNUczCZ7Z+o9v7HS8iQURLIwj5BF9ZJQouP0MDtlw=; b=thwLZ2yv2QnsUMMJaVtQIwZj5inKuf+E867pklP0iHY2VE27m0fl+uj0PorL4fUQ54 +ioXLnz0/UOml2mPunf7ViGTC9BjQG5D6KdzGzt0iY36FyBZWdX1quU7U/gGbSaunIUg H3w1FtQC0ilda2Ki3pRyGPphljJ4Kud55eobI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=kkQByESfGdqCSGUigIsScGEenOUYxcH8CRoP3LTzLOdGgTiDSTObojw50QPNP1P42T vrKTz8jjwVEWSnj43AyuAKkwIRLbjx+fkWu8sva5yIpgheiWa9Bjj8qnAe3dYryS8vSd yad5izGPeZck9lD+fV9zdXB2cxq2r3RAb721I= Received: by 10.91.19.4 with SMTP id w4mr5468886agi.0.1257413788923; Thu, 05 Nov 2009 01:36:28 -0800 (PST) Received: from smtp.gmail.com (c-98-210-130-131.hsd1.ca.comcast.net [98.210.130.131]) by mx.google.com with ESMTPS id 21sm888664yxe.19.2009.11.05.01.36.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Nov 2009 01:36:27 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Thu, 05 Nov 2009 01:36:18 -0800 Date: Thu, 5 Nov 2009 01:36:18 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Cc: bangert@gentoo.org Subject: Re: [gentoo-dev] a pragmatic approach to FEATURES [was FEATURES use or misuse?] Message-ID: <20091105093618.GD25976@hrair> References: <200911031648.04090.patrick@gentoo.org> <20091104193617.0248c03a@gentoo.org> <20091105045657.GB25976@hrair> <200911050949.10627.bangert@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7qSK/uQB79J36Y4o" Content-Disposition: inline In-Reply-To: <200911050949.10627.bangert@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 00dc194e-6c31-42f5-b551-b50cdd8d03d4 X-Archives-Hash: 9ee9eb0a35eed823ea873bbd8a5f0e9f --7qSK/uQB79J36Y4o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 05, 2009 at 09:49:07AM +0100, Thilo Bangert wrote: >=20 > > Perhaps the pragmatic approach might be wise. > >=20 >=20 > when filing the FEATURES bugs, i (IIRC) tried to remain on the pragmatic= =20 > side, recognising the sometimes non-existing alternatives. ie. i didnt=20 > open bugs for each and every FEATURES usage. >=20 > the tracker bug is here: > http://bugs.gentoo.org/show_bug.cgi?id=3D174335 While I appreciate you being pragmatic in your cleanup efforts, you=20 miss the point of my post- while FEATURES reliance needed a valid=20 reason from a QA standpoint, it was *valid* from a format standpoint=20 prior to paludis/PMS (and was the only option in some corner cases=20 ebuild wise). The response these days when it comes to FEATURES is that you cannot=20 rely on it's existance ever- this loops back to my point about=20 pragmatism. I understand PMS/paludis wishing to duck the vars existance to make it=20 go away, but I don't think it's a tenuable approach- as you yourself=20 said above, in trying to do this cleanup you recognized that sometimes=20 there was no alternative. Please understand my point here is QA; not picking a fight. That=20 said, paludis doesn't do anything FEATURES wise due to PMS not=20 mandating they do so... as you said, certain ebuilds rely on it's=20 existance to work. This means via PMS being incomplete, paludis isn't going to play nice=20 in those cases (corner case- if the user defines the var themselves in=20 their config, this would address it). Essentially, you can't use FEATURES but you have to in some cases. =20 Doing so however doesn't necessarily play nice w/ paludis due to=20 stepping outside of PMS. Classic catch 22. Rather then letting the problem persist, I'd rather see folk take a=20 look at FEATURES/PMS and identify what needs to be pushed in to take=20 care of the cases where there is no alternative to 'hasq some-feature=20 $FEATURES' rather then us just collectively sticking our heads in the=20 sand. Grok? Or we can just keep ignoring the problem pretending it's a user config=20 issue rather then a format level issue... ~harring --7qSK/uQB79J36Y4o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkrynJIACgkQsiLx3HvNzgc+FQCgki6dtSxPaeFrkzn6BnDc84P5 LRgAoMRkzZO+c8ej0kA5pHebtKwsBQJx =x3FV -----END PGP SIGNATURE----- --7qSK/uQB79J36Y4o--