On Thu, Mar 29, 2007 at 10:04:57PM +0100, Ciaran McCreesh wrote: > On Thu, 29 Mar 2007 22:47:46 +0200 > Thomas Rösner <[EMAIL PROTECTED]> wrote: > > Other things I want from Gentoo right now depend on factors other > > than the package manager, too; prebuilt packages > > 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 with a single file for the entire cache anyways. If you're not doing remote, the few seeks required for xpak aren't killer. Granted, a cache can help, but it's design choice for the format. With tbz2, you can unpack if you're completely screwed manager wise; transfering binpkgs around doesn't require copying two files (as your 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) into portage then. The slowdown isn't due to the format, it's due to the freaking craptastic implementation that snuck in. Short version, remote binpkg v1 (existing in portage) is designed around simply making the normal on disk repo sharable via apache/ftp/whatever, no mods/transformations required; goes without saying, what works for local access doesn't mean it's going to work for remote. Design of it requires several roundtrips per individual package lookup. It was a quick and dirty hack, and did the job frankly. Integrate solars caching format, the repo just becomes akin to how debian/rpm distros do it- pull down a cache, operate on the cache locally. Fairly fast in my own playing for pkgcore. > > binary-breakage protection > > 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 the finger, assuming you intend on integrating collision-protect one of these days. Meanwhile, kudos, portage already has this- FEATURES=preserve-libs. Haven't looked to see if it's been released yet, although it's 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 things), but it's in. Finally, regarding the weekly portage fud, probably worth noting that despite the claims about "portage source being absolute crap, 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 contradicts fair bit of BS regarding portages internals. First two involve pretty heavy mods to the "unmodifiable" internals, rest are demonstrations of usage of the apis, which surprisingly, isn't that bad. Certainly not how I'd do it given the ability to do a cleanslate, but "I prefer a different approach" doesn't automatically mean "it's shite folks". Part of the usual rant comes down to a long standing meme from pre .51.* days; code back then *was* pretty fricking ugly in spots. I used to call it "c code written in python" for example- quite a large amount of refactoring since then has changed that. It ain't perfect (base design forced by the legacy API for example is a core reason for pkgcore even existing), but it's certainly not as bad as ciaran paints it. Very least, please take the time to actually dig into the source and form your own opinion, instead of just accepting it as fact because he repeats it damn near daily. ~harring
pgpDdoDleOuuf.pgp
Description: PGP signature
