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 1NJDdC-0004UH-VP for garchives@archives.gentoo.org; Fri, 11 Dec 2009 22:06:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 972C9E0916 for ; Fri, 11 Dec 2009 22:06:34 +0000 (UTC) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by pigeon.gentoo.org (Postfix) with ESMTP id B68C1E08D6 for ; Fri, 11 Dec 2009 20:32:05 +0000 (UTC) Received: by gxk28 with SMTP id 28so1374239gxk.9 for ; Fri, 11 Dec 2009 12:32:05 -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=sI8T/Z7l/oWo9r2JcEjqVAnmtExEk+HEl/hLXSwNAB8=; b=UqAhdRL8uNv5h7Dt2vN/BIcWKiiA4fqycuvilj3gsKTwQj40Emy0Oog3W9+V/ggYwr 4XANyCu03gw9TqzFqim61reSWX8lhFKvNkTsjP79prH5Gg1KHjfOGt7f1l0CMKAqmJWA cFDorliYyPpQ6sBNzpSCKnQ2pstQ/QWANYR/w= 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=I1gKVB/iJBpEZicgy/kzmw6oOfpDa+CWIvvCd5osRhnwtpMWa/DV2QADZAZPZjbru1 bbIh/q1WhU4t0UDjrv/hwY7BnBm/zWbY/1tHvg4XFhTzGV/Nu46+DwItzjyTo9x8vkQw J6s84NZEoRbUnjpg4xpeRKO05uE5cmZT955sU= Received: by 10.151.88.42 with SMTP id q42mr3298199ybl.75.1260563525419; Fri, 11 Dec 2009 12:32:05 -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 21sm1011875yxe.55.2009.12.11.12.32.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Dec 2009 12:32:04 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Fri, 11 Dec 2009 12:30:22 -0800 Date: Fri, 11 Dec 2009 12:30:22 -0800 From: Brian Harring To: Ciaran McCreesh Cc: gentoo-pms@lists.gentoo.org Subject: Re: [gentoo-pms] kdebuild-1 conditionales Message-ID: <20091211203022.GG6529@hrair> References: <19234.23228.586356.915011@a1i15.kph.uni-mainz.de> <20091211170245.053f6f16@snowmobile> <19234.32055.471891.86138@a1i15.kph.uni-mainz.de> <20091211171814.76d7e286@snowmobile> <19234.33425.281151.673508@a1i15.kph.uni-mainz.de> <20091211174339.6489c086@snowmobile> <19234.35855.201822.274984@a1i15.kph.uni-mainz.de> <20091211182739.28626e85@snowcone> <20091211194241.GF6529@hrair> <20091211195332.739e4c63@snowcone> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Package Manager Specification discussions X-BeenThere: gentoo-pms@gentoo.org X-BeenThere: gentoo-pms@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lHGcFxmlz1yfXmOs" Content-Disposition: inline In-Reply-To: <20091211195332.739e4c63@snowcone> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 75c53f1c-cc82-4a22-af0b-3e842a3dc51e X-Archives-Hash: 1875edde711bc08a17dd35feef6912f0 --lHGcFxmlz1yfXmOs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 11, 2009 at 07:53:32PM +0000, Ciaran McCreesh wrote: > On Fri, 11 Dec 2009 11:42:41 -0800 > Brian Harring wrote: > > Bluntly, you would be pissed if you got stuck having long term > > support for an experimental eapi I split w/out consult- why do you > > think that the reverse wouldn't hold? >=20 > No, if a large project such as, say, the Gentoo KDE project, had asked > you for support for a well documented EAPI and you had provided it, I > would have also implemented that EAPI in Paludis. >=20 > kdebuild-1 was not done without consultation. It was the result of a > considerable amount of work from an official Gentoo project, and it was > a well defined, published standard. It was in no way an experiment. And if gnome decides they want their own format, is PMS/eapi stuck w/=20 the bill? > > Regardless, if you didn't plan for phasing out an experimental eapi,=20 > > it's not the mainstream eapi's problem- it's your mess to clean up. >=20 > kdebuild-1 was not experimental. It wasn't official, thus *you* can view it was non-experimental w/in=20 the paludis realm, but it's experimental to gentoo as a whole- the=20 primary pkg manager, the official manager specifically, didn't even=20 support it. It was experimental. > > What I find pointless about this discussion is this notion that=20 > > because you jammed kdebuild into the official eapi doc, the pms team=20 > > in it's current incarnation is responsible for keeping kdebuild=20 > > around and cleaning up that mess. >=20 > No no no. Because the Gentoo PMS project, at the request of the Gentoo > KDE project, included support for one of their published EAPIs, the > Gentoo PMS project would be irresponsible to just remove it without > ensuring that it won't affect users. PMS was irresponsible for allowing it into the official eapis in the=20 first place. If KDE intended it to be supported long term (which I=20 strongly doubt, it was an overlay of unstable ebuilds after all), then=20 they too were irresponsible. Frankly, it's irresponsible of PMS right now to leave it in the docs-=20 I've seen too much confusion from users about what is supported/not=20 because of it. That *is* irresponsible to leave in place. > > 2) write a converter. As said, since it's only *rm phases you really= =20 > > have to care about for allowing it to be removed by other managers,=20 > > this isn't incredibly hard- further, full metadata rewrite is > > probably possible w/ eapi2 bits. >=20 > Writing a converter is more work than a simple phased removal. I didn't imply a full format converter. I implied a converter that=20 tweak it enough the thing could be uninstalled by *any* package=20 manager supporting eapi2. I'd expect that would cover a significant=20 majority of any remaining (if even there are remaining) installed=20 pkgs. > > That solves it technically, rather then just ignoring it and=20 > > pretending we won't have this exact discussion a year later w/ the=20 > > same claims as to why it can't be removed. >=20 > A year later, we can easily have had kdebuild-1 removed in a > responsible manner. You have zero stats now to backup that statement- basically your=20 prediction of when it'll be fine to remove it is based on opinion. Via the same rules, my opinion is that it's fine to remove it now. 1=20 -1 =3D 0. Back this up w/ stats please in the future. > > Additional thing- note the compromise I mentioned, adding into PMS=20 > > urls directing users where to go for experimental format information,= =20 > > or to get at old/dead official eapis. If they can't catch a=20 > > paragraph upfront telling them where to look, it's their problem. >=20 > More work than just doing it properly. Depends on your definition of 'properly'. I presume what you mean is=20 that it requires you to maintain a kdebuild pms pdf somewhere- more=20 work for you. My stance, it's more work for the rest of us coding around the ifdef=20 mess (most recent bitchfest from it was grobian doing the prefix=20 patch). Properly to me means using the dvcs's capabilities, and making it=20 easier for folks to do *official* eapi work w/out having to maintain=20 dross someone shoved into it. Move the effort of maintaining kdebuild=20 bits to those who are responsible for it, effectively. > > Finally, and I admit this is a bit barbed- any user who install this=20 > > eapi should've known it was experimental and that they could get=20 > > support for it for paludis only. If the user thought it was someday=20 > > going to become an official eapi, that's the user/managers problem,=20 > > not ours. >=20 > kdebuild-1 was not experimental. It was an official Gentoo KDE project > EAPI. Goodie on them. Note that it's "official gentoo kde project", not=20 "official eapi". Then they can maintain it w/ paludis, rather then the current PMS=20 incarnation being stuck with it. > > More importantly, pms's responsibility/purpose for gentoo is=20 > > presenting users with documentation on the *official* eapis- forcing=20 > > kdebuild bits into that doc misleads users into thinking kdebuild is=20 > > official, thus supported. User confusion there is, and has been,=20 > > rather annoying. >=20 > And at the time, the Gentoo KDE project considered kdebuild-1 to be an > official EAPI. And they have zero ability to define what is an official EAPI. =20 Misunderstanding reality bluntly, is their problem. As I said, are we on the hook if gnome decides they want their own=20 format? No. Further, note prefix- that is a far more widespread deployment of an=20 experimental eapi, longer lived (and still living even). PMS ain't on=20 the hook for their experimental work- they went and got it approved as=20 an EAPI, for the new EAPI pms is *now* on the hook. That's the proper way to have an official eapi. Someone=20 misunderstanding reality, or misrepresenting reality and claiming an=20 experimental eapi is 'official' is not our problem, and not even=20 remotely something we should be bound by. I'll note finally that when gentoo-kde went and had their brief liason=20 w/ kdebuild, the issues of long term support of the format were known-=20 further it was made abundantly clear to them that from portage/pkgcore=20 standpoint it was an experimental eapi and there wasn't a gurantee=20 we'd ever implement it (in my case I'm reasonably sure the phrase=20 "when hell freezes over" was uttered more then once). I'm sorry if this causes folks any issue, but both paludis and=20 gentoo-kde knew what they were getting into when they went down this=20 path. Frankly I really don't think any users are going to be affected=20 by punting this out of PMS- paludis still carries the support (and is=20 the users only option from day one for removing those packages) You're arguing this must remain in PMS so that folks implementing=20 managers can see it. Nobody is going to implement kdebuild- at best I=20 may write a converter just to bail those users out, but that's likely=20 the extent of effort people will extend on cleaning it up. Beyond that, a compromise was offered so that experimental eapis, and=20 dead/old eapis can be retired from the document. Gentoo doesn't really even need to do that- that's just an attempt to=20 be nice and compromise. If that's not good enough, frankly, tough=20 cookies from where I'm sitting. ~harring --lHGcFxmlz1yfXmOs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAksiq94ACgkQsiLx3HvNzgcOzgCcCzFkXsAYpePlJVgsH3mCbx5l TckAoKljjneQfmwUElmt1zwj6J0RlzD9 =zc3z -----END PGP SIGNATURE----- --lHGcFxmlz1yfXmOs--