From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1HZb5j-0006uh-Jg for garchives@archives.gentoo.org; Thu, 05 Apr 2007 23:10:08 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l35N8Zju000462; Thu, 5 Apr 2007 23:08:35 GMT Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l35N47UF026399 for ; Thu, 5 Apr 2007 23:04:07 GMT Received: from seldon (c-67-171-130-60.hsd1.or.comcast.net[67.171.130.60]) by comcast.net (rwcrmhc11) with SMTP id <20070405230405m11005hs5le>; Thu, 5 Apr 2007 23:04:05 +0000 Date: Thu, 5 Apr 2007 16:04:05 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April Message-ID: <20070405230405.GC13118@seldon> References: <20070401092940.1B4C26441E@smtp.gentoo.org> <200704052240.56083.kugelfang@gentoo.org> <20070405212406.GA13118@seldon> <200704060016.18194.kugelfang@gentoo.org> <20070405221147.GB13118@seldon> <46157B2E.8060607@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@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="JgQwtEuHJzHdouWu" Content-Disposition: inline In-Reply-To: <46157B2E.8060607@gentoo.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: 7d381b6b-6837-4c39-9e8e-f79e59140589 X-Archives-Hash: f108389a33fd858c19d9fab3547cdc07 --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2007 at 12:41:50AM +0200, Vlastimil Babka wrote: > Brian Harring wrote: > >>> Breaking EAPI=3D0 via pushing slot deps in isn't much of an option in > >>> my opinion; usual "needs to have been on release media for at least 6 > >> We can push for an EAPI=3D1 =3D=3D (EAPI=3D0 + slot deps)... > > > > Can, yep, although that was originally blocked by "EAPI=3D0 must be=20 > > defined", which folks seem to have backed off on. >=20 > Not sure if slot deps themselves could even replace version ranges hacks > without also solving bug 4315 (native version ranges) in all cases. IMHO > it should be possible at least to specify slot+usual version limit, to > make it worth EAPI bump. >=20 > > One issue with adding EAPI=3D1 having just slot deps is that it skips= =20 > > out on some long term changes intended- default src_install for=20 >=20 > So what, longer term changes could wait for EAPI=3D2. Why not make > experience with EAPI bumping with something smaller for a start, instead > of trying to make one big bump that will bring all changes we can think > of now, but will be implemented only in 2010... A 101 small little bumps results in a general pain in the ass for=20 ebuild devs; if a change is ready to go for EAPI=3D1 (whether=20 implemented now, or bloody simple), and folks *agree to it*, then it=20 should go in. I'm not advocating waiting for every little thing to be shoved in. =20 That said, there are lots of minor tweaks that have been desired, but=20 haven't been implementable since they would break backwards=20 compatibility and no versioning scheme existed. I've got a list floating around somewhere of the specifics, but top of=20 the head- 1) killing DEPEND/RDEPEND autosetting once and for all 2) shift the default phase funcs into a fake eclass; basically the=20 base_src_compile example in the previous email. 3) default src_install (currently is empty) 4) *potentially* chunking up src_compile into src_configure and=20 src_compile. 5) slightly addressed via #2, a 'prepare phase' for patching and other=20 crap. Not a huge fan, but it's also not something I'm pushing. 6) drop useq/hasq 7) whatever api additions required to remove the need for raw vdb=20 access by ebuilds (contents, IUSE, and USE seem to be the primary ones=20 atm till use deps are available). 8) potential, although it requires work- glep33. I'd probably be=20 willing to do the portage modifications for that one; upshot of it is=20 that it allows breaking eclass api as needed, further reorganizes=20 their on disk layout so signing/manifests can sanely be integrated. So... #8 is slightly large admittedly. Rest are pretty damn minor,=20 bit of discussion required, but minimal real work to code it- stuff=20 like that, no reason *not* to slide it into eapi=3D1. > Now it may look like I contradict myself saying to bump ASAP but not > without solving bug 4315 first. But I see slot deps without limits only > half of a feature. So far, the syntax I've seen for 4315 has made me want to club baby=20 seals, hit the hash pipe, and make a run for the presidency... Offhand, majority of the tree issues can be addressed via slot deps-=20 the remaining chunks that can't, can be addressed via a slightly=20 smarter resolver combined with folks using blockers- simple example,=20 need >=3D1.3 < 2.0 for a non-slotted package, use ">=3D1.3 !>2.0". Can=20 invert it to "<2.0 !<1.3" if you prefer, although the latter is=20 slightly preferable on the offchance the package some day becomes=20 slotted. Granted, it's not perfect- point is it's actually doable now without=20 format changes. Other question there is how many ebuilds in the tree actually *need*=20 this, beyond just slot deps. Either way, folks ought to chime in... ~harring --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGFYBksiLx3HvNzgcRAjP3AJ97OpAFCRy64KteQKXxujloTzBx4QCgjCwG 9h4gdqGyuOaIE4GdbkDOSXc= =AdC3 -----END PGP SIGNATURE----- --JgQwtEuHJzHdouWu-- -- gentoo-dev@gentoo.org mailing list