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.54) id 1EnnR0-0004HK-8E for garchives@archives.gentoo.org; Sun, 18 Dec 2005 01:33:58 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBI1WBOW021682; Sun, 18 Dec 2005 01:32:11 GMT Received: from cubert.e-centre.net (morbo.e-centre.net [66.154.82.3]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBI1TElN005909 for ; Sun, 18 Dec 2005 01:29:15 GMT Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1EnnMQ-0005WS-I3 for gentoo-dev@lists.gentoo.org; Sat, 17 Dec 2005 20:29:14 -0500 X-ASG-Debug-ID: 1134869353-7546-146-0 X-Barracuda-URL: http://10.3.1.19:8000/cgi-bin/mark.cgi Received: from et-pdx-2.site.stayonline.net (unknown [65.200.64.131]) by barracuda2.stayonline.net (Spam Firewall) with ESMTP id B549DB235B for ; Sat, 17 Dec 2005 20:29:13 -0500 (EST) Received: from nightcrawler ([172.16.1.202]) by et-pdx-2.site.stayonline.net (8.12.6/8.12.6) with ESMTP id jBI1T25j004860 for ; Sun, 18 Dec 2005 01:29:02 GMT Date: Sat, 17 Dec 2005 17:28:52 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org X-ASG-Orig-Subj: Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates Subject: Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates Message-ID: <20051218012852.GG22142@nightcrawler.e-centre.net> References: <200512140911.51446.jstubbs@gentoo.org> <20051214005202.34958472@snowdrop.home> <200512142109.02622.jstubbs@gentoo.org> <20051214180221.5136cf94@snowdrop.home> <43A0933D.1010402@gmail.com> <20051214215406.33fed83f@snowdrop.home> <20051217233318.GC22142@nightcrawler.e-centre.net> <20051218001430.0d78fe4b@snowdrop.home> <20051218005104.GE22142@nightcrawler.e-centre.net> <20051218010727.5528f28f@snowdrop.home> 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="NY6JkbSqL3W9mApi" Content-Disposition: inline In-Reply-To: <20051218010727.5528f28f@snowdrop.home> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.6393 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: 7cbea56f-2c42-4f94-a936-c67b7232f008 X-Archives-Hash: cf0a7e2a1c0452c65088cfb09923adc4 --NY6JkbSqL3W9mApi Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 18, 2005 at 01:07:27AM +0000, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 16:51:05 -0800 Brian Harring > wrote: > | Transitioning from single news.unread to N is going to break clients=20 > | that expect a single. >=20 > Yup. >=20 > | As I said, you're going to break stuff- and you're building it into=20 > | your glep out of (aparent) stubborness. >=20 > No no. I'm just not adding something ill defined and arbitrary to the > GLEP to avoid introducing minor possible breakage when some ill defined > and arbitrary change is made to Portage. Well, since we're toeing the line, I'll just state your glep is ill=20 defined and arbitrary, it is inflexible and incomplete due to the fact=20 it doesn't take into consideration the existing solutions (namely overlays). Back off the technical double speak insults unless you want others=20 people to get nastier then they are already. > | What do you want, another glep amending yours with that one little=20 > | detail? >=20 > Probably won't be necessary... If you're unwilling to make your 'flexible' proposal actually flexible=20 for anything but your stuff (eselect), either the glep is going to be=20 fought tooth and nail or a competing glep is going to come out of=20 this. Bluntly, stop being a tool, users want this feature, stop using it as=20 fodder to fight. > | The news glep crosses several groups, collaboration here is required,= =20 > | meaning *listen* to the folk you're trying to command. Otherwise the= =20 > | glep *will* go nowhere no matter how much noise you make. >=20 > And I'm asking you to provide me with a specification of how multiple > repositories will work. Without that, there's no way the GLEP can be > made to handle multiple repositories. We have overlays already. That *is* multiple repositories. Stop trying to dodge the request by making us waste our time and=20 produce a stand alone repository glep- overlays exist *now*, thus you=20 *do* need to address them *now* else your glep is incomplete. > | > | If you're going to create and dump a mess on us, I expect it to > | > | be in the proposal- especially since your proposal is > | > | intrinsically portage bound. > | >=20 > | > There's very little that's Portage bound. As originally requested, > | > I've tried to keep as much as is reasonably possible *out* of > | > Portage... > |=20 > | It's distributed via the portage tree, it's updated by portage, the=20 > | check for new news items is *via* portage, and check for news items=20 > | prior to merging is done by portage. > |=20 > | If that truly was your intention, you failed in it.. It's bound to=20 > | portage, despite the rhetoric. >=20 > No no. A Portage bound solution would stick all the code and clients in > Portage proper, rather than using Portage merely for hooks as far as is > reasonably possible. Word games... You're dodging my point. > | Word games suck, instead of playing them you *should* be trying to=20 > | address the concerns- iow, what do you *explicitly* need from > | portage,=20 >=20 > What explicitly I need, *if* the GLEP is to specify multiple repository > support from the outset, is a specification of how Portage will handle > multiple repositories conceptually and a description of the interface > that will be provided by Portage. Overlays. The only thing you need is a repo id, the only thing we need is to know=20 what you'll be accessing, what we need to future proof from an api=20 standpoint. > | > Especially since you've said "we're not doing it the way you think > | > it should work"... > |=20 > | Where have I stated that? My statements thus far about multi repo=20 > | were in reference to a glep that missed the target. > | > | Provide quotes please, or get back to nailing down exactly what you=20 > | need portageq wise so we can state "do it this way, and we'll shut=20 > | up". >=20 > I'm thinking mainly about "Portage externally will use user defined" in > relation to repository identification. Any specification on multiple > repositories that comes from me will have said identifiers being > repository designed, simply because I can't see a sane way of handling > it otherwise. We've had this discussion once already, but I'll keep hammering the=20 point till you follow it- external repo label is just that, what the=20 user would specify on commandline. emerge --repo blah --rsync (fex). Internal ids are a seperate beast, and a simple solution *now* is that=20 any repo that provides new must bundle an ID. Do that, and portage can made to use it for your news crap. Aliasing=20 (user naming) is something *we* would add as a feature down the line. Why am I stating it as such? Because again, overlays exist now, and=20 your glep is willfully leaving them out in the cold. > | You want us to nail everything down for our request, I'd like you to=20 > | do the same (especially since we're stuck maintaining whatever you=20 > | propose/create). >=20 > I can't nail down details on multiple repository support until I'm told > what Portage will do. Give me a specification for what Portage will do > and I'll quite happily make the GLEP work with it. Overlays have existed for at least 2 years. Theres your spec. Time to amend your glep so it actually encompasses=20 them, especially considering your glep is a modification of the tree=20 format. ~harring --NY6JkbSqL3W9mApi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDpLtTvdBxRoA3VU0RAvsxAJ46M9sW8d8ug0ikbUaQe289C5QysgCfR3+g E9cjwXpRytshv3ympZOZucU= =0hkG -----END PGP SIGNATURE----- --NY6JkbSqL3W9mApi-- -- gentoo-dev@gentoo.org mailing list