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 1HXD7q-00076R-NO for garchives@archives.gentoo.org; Fri, 30 Mar 2007 09:10:27 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l2U99R4T024730; Fri, 30 Mar 2007 09:09:27 GMT Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [204.127.192.84]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l2U97an1022549 for ; Fri, 30 Mar 2007 09:07:37 GMT Received: from seldon (c-67-171-130-60.hsd1.or.comcast.net[67.171.130.60]) by comcast.net (rwcrmhc14) with SMTP id <20070330090733m1400ikjuue>; Fri, 30 Mar 2007 09:07:34 +0000 Date: Fri, 30 Mar 2007 02:07:33 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [soc] Python bindings for Paludis Message-ID: <20070330090733.GA19502@seldon> References: <200703251403.38629.vapier@gentoo.org> <4606BF5C.9060304@klever.net> <200703271519.29674.vapier@gentoo.org> <20070327211510.0b426e09@snowflake> <308E0F46-7457-48E2-956F-23FB8439B6FD@gentoo.org> <20070329095658.2851e8c4@snowflake> <1175194656.15394.38.camel@onyx.private.gni.com> <20070329200608.3b2c2b6f@snowflake> <1175196300.15394.45.camel@onyx.private.gni.com> <20070329210224.65c7a1fd@snowflake> 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="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <20070329210224.65c7a1fd@snowflake> User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: 5edaa4b2-b71a-4106-a7f2-53af1e0f351f X-Archives-Hash: e66e3855424b0f364ec7d2cd0ccc5c5b --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2007 at 10:04:57PM +0100, Ciaran McCreesh wrote: > On Thu, 29 Mar 2007 22:47:46 +0200 > Thomas R=C3=B6sner wrote: > > Other things I want from Gentoo right now depend on factors other > > than the package manager, too; prebuilt packages >=20 > A package manager that supports a better binary package format > (split out local metadata would be a good start) Not really a huge gain; if you're attempting remote, you're better off=20 with a single file for the entire cache anyways. If you're not doing=20 remote, the few seeks required for xpak aren't killer. Granted, a cache can help, but it's design choice for the format. =20 With tbz2, you can unpack if you're completely screwed manager wise;=20 transfering binpkgs around doesn't require copying two files (as your=20 ebin format does). > it's even doable with Portage's binaries, although according to a > Gentoo-based distribution that tried it, your 30 minutes would be > optimistic for -uDpv world... Said derivative should look into adding remote binpkg v2 (solars work)=20 into portage then. The slowdown isn't due to the format, it's due to=20 the freaking craptastic implementation that snuck in. Short version, remote binpkg v1 (existing in portage) is designed=20 around simply making the normal on disk repo sharable via=20 apache/ftp/whatever, no mods/transformations required; goes without=20 saying, what works for local access doesn't mean it's going to work=20 for remote. Design of it requires several roundtrips per=20 individual package lookup. It was a quick and dirty hack, and did=20 the job frankly. Integrate solars caching format, the repo just becomes akin to how=20 debian/rpm distros do it- pull down a cache, operate on the cache=20 locally. Fairly fast in my own playing for pkgcore. > > binary-breakage protection >=20 > Funnily enough... That one can be done without tree changes too via > something we're calling reparenting. There're some vague suggestions of > roughly how to do it at [1]. literal re-parenting is a grand way to make collision-protect give you=20 the finger, assuming you intend on integrating collision-protect one=20 of these days. Meanwhile, kudos, portage already has this- FEATURES=3Dpreserve-libs. Haven't looked to see if it's been released yet, although it's=20 been around for just over a month so no clue if it's been released yet. Personally hate the feature (revdep-rebuild issues among other=20 things), but it's in. Finally, regarding the weekly portage fud, probably worth noting that=20 despite the claims about "portage source being absolute crap,=20 unmodifiable", example above contradicts that bit. Further... * parallelization patches in bugzie * long term co-exinstance of prefix branch * several portage guis * packages.gentoo.org (surprise surprise, it uses portage) all of which are created/maintained by non-portage developers=20 contradicts fair bit of BS regarding portages internals. First two=20 involve pretty heavy mods to the "unmodifiable" internals, rest are=20 demonstrations of usage of the apis, which surprisingly, isn't that=20 bad. Certainly not how I'd do it given the ability to do a=20 cleanslate, but "I prefer a different approach" doesn't automatically=20 mean "it's shite folks". Part of the usual rant comes down to a long standing meme from pre=20 =2E51.* days; code back then *was* pretty fricking ugly in spots. I=20 used to call it "c code written in python" for example- quite a large=20 amount of refactoring since then has changed that. It ain't perfect=20 (base design forced by the legacy API for example is a core reason=20 for pkgcore even existing), but it's certainly not as bad as ciaran=20 paints it. Very least, please take the time to actually dig into the=20 source and form your own opinion, instead of just accepting it as fact=20 because he repeats it damn near daily. ~harring --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGDNNVsiLx3HvNzgcRAnFMAKDDO8ss7DF5hxRglJ+ZcC5J9xhHlwCgw9a3 KZ2c3l7mXcONE+8TtLXIMsE= =K26n -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- -- gentoo-dev@gentoo.org mailing list