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 1Euvdj-0006gH-RZ for garchives@archives.gentoo.org; Fri, 06 Jan 2006 17:44:36 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k06Hh6pm023596; Fri, 6 Jan 2006 17:43:06 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 k06HdPNJ021102 for ; Fri, 6 Jan 2006 17:39:25 GMT Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1EuvYj-0007iP-Bp for gentoo-dev@lists.gentoo.org; Fri, 06 Jan 2006 12:39:25 -0500 X-ASG-Debug-ID: 1136569164-14705-449-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 896FADC71F for ; Fri, 6 Jan 2006 12:39:24 -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 k06HdB5j023991 for ; Fri, 6 Jan 2006 17:39:11 GMT Date: Fri, 6 Jan 2006 09:39:02 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org X-ASG-Orig-Subj: Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas Subject: Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas Message-ID: <20060106173901.GF28075@nightcrawler.e-centre.net> References: <43BDF53C.8080205@leetworks.com> <20060106053556.GD28075@nightcrawler.e-centre.net> <623652d50601060100w2bd03634i@mail.gmail.com> <1136559950.18383.11.camel@cgianelloni.nuvox.net> 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="E7i4zwmWs5DOuDSH" Content-Disposition: inline In-Reply-To: <1136559950.18383.11.camel@cgianelloni.nuvox.net> 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.6991 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: 15ea4ab4-ca4d-4995-94e1-786ca7d4873c X-Archives-Hash: 04ac63b1b188019910e51fe2e84943c7 --E7i4zwmWs5DOuDSH Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote: > On Fri, 2006-01-06 at 09:00 +0000, Chris Bainbridge wrote: > > On 06/01/06, Brian Harring wrote: > >=20 > > > Probably better to iron out what y'all actually need and what the dev > > > community is willing to put up with. > > > > > > Eg, would do some research into it, read the archives from last few > > > wars over it, in general find (and address) the issues that lead to > > > glep19 going still born. > >=20 > > The problems being: > >=20 > > 1) Manpower. There are already 10,000 open bugs in bugzilla (and > > growing) without adding more. >=20 > This is probably the primary reason it died. This, of course, ties in > greatly to #2. Automation can reduce workload, within limits. Fex, scripting for=20 yanking packages/deptree out of normal tree for merging into a g19=20 tree. Doing it by hand is possible, but error prone- same reason we have=20 ekeyword, bit harder to screw things up via ekeyword (and it's a bit=20 quicker in use then loading up $EDITOR). > > 2) Lack of interest. Most developers aren't interested in supporting > > "old" packages. I tend to believe interest is there- specifically resources/manpower=20 to do it. That said, I don't think anyone has yet provided the folks who are=20 interested any way to help- hell, can't even tap interested folk to=20 help with maintaining the ebuild subset at this point since their is no=20 subset.=20 Hell, script work that needs be done, nothing has been done in that=20 direction either- again, specifics haven't been stated, so there isn't=20 anything to contribute on. Not going to find people doing all the work for you, but if=20 _something_ were available for people to build from I'd expect more=20 folks to jump in and help. > The only real "subset" that can easily work without dramatically=20 > increasing workload is to limit to only arch rather than both arch=20 > and ~arch. This is simply because it can be scripted. Agreed on pulling from arch. > > 3) The enterprise. Both of the above problems would be fixed if > > enterprises were contributing developers and/or money. However, they > > aren't, so why is that? The truth is most enterprises want to go to a > > big company to buy their software. They want one homogeneous binary > > system, not a flexible way of building packages from source, and they > > want someone else to do it and be responsible for it. >=20 > While I don't think enterprise support is necessary to accomplish a > stable portage tree, it certainly wouldn't hurt. Tend to think either we wait for someone to step in and contribute=20 (potentially waiting a _long_ time), or just do it. Kind of obvious my preferred route is "just do it" ;) > Truthfully, for any "large" enterprise, the company will be maintaining > a fair number of their own packages, with custom patches and whatnot. > Where I work, we use Red Hat Enterprise Linux. Why? Because we can pay > for support. That isn't the point I am going to make here, however. We > also have to maintain several hundred RPM packages that either are not > included in RHEL or modified by us in some way. What this means is we > are now in the business of maintaining a package set, using arguably > inferior tools versus ebuilds and portage. The binary support in > portage does make it very possible to "build once, deploy everywhere" > quite easily. The binary support is a bit weak- realistically, for a binpkg distro=20 based off of gentoo, it would need a bit of an enema to improve it. =20 So... consider that a statement of "proposals welcome on how to=20 improve it". Right now, since (same with ebuild support) the format=20 is effectively hardcoded into portage, it's hard to replace/make large=20 changes to binpkg format. Abstraction work has/is underway to resolve=20 that (something that help would be appreciated on also). ~harring --E7i4zwmWs5DOuDSH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvqs1vdBxRoA3VU0RArsfAJwKw+1dITJhjdUoTQ3sQ35NZDJ5oQCeMQk0 +fDBPxAPaV6AdSibDDx+Nl4= =rs5W -----END PGP SIGNATURE----- --E7i4zwmWs5DOuDSH-- -- gentoo-dev@gentoo.org mailing list