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

[Brian Harring]

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.

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