On Fri, 30 Mar 2007 02:07:33 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > 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.
*shrug* I was thinking local or fast-access to metadata, remote and potentially slow binaries, personally. There are several viable ways of doing it. From benchmarking, a single file cache tends to end up being slower than multiple files for operations that don't involve inspecting most of the tree. It's not a huge issue, and the difference is tiny in comparison to the way Portage does things currently... > > > 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 Well yes, but no-one sane is talking about literal reparenting, because there are far better solutions that're almost as easy to implement. > assuming you intend on integrating collision-protect one of these > days. Hm? No-one's found it interesting or useful enough to ship it as core with Paludis. It's available as a third party hook for anyone who wants it... > 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. We're talking about doing it properly, as you know all too well... > 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. And think what there would be if Portage had a decent API and internals... > 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. Better than it was is hardly a glowing commendation... I'd use the well known technical description involving polishing here, but someone would just pretend that it's offensive... -- Ciaran McCreesh
signature.asc
Description: PGP signature
