Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

On Fri, 30 Mar 2007 02:07:33 -0700
Brian Harring <ferringb@×××××.com> 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 <Thomas.Roesner@××××××××××××××.de> 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