Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [soc] Python bindings for Paludis
Date: Fri, 30 Mar 2007 09:10:27
Message-Id: 20070330090733.GA19502@seldon
In Reply to: Re: [gentoo-dev] [soc] Python bindings for Paludis by Ciaran McCreesh
1 On Thu, Mar 29, 2007 at 10:04:57PM +0100, Ciaran McCreesh wrote:
2 > On Thu, 29 Mar 2007 22:47:46 +0200
3 > Thomas Rösner <Thomas.Roesner@××××××××××××××.de> wrote:
4 > > Other things I want from Gentoo right now depend on factors other
5 > > than the package manager, too; prebuilt packages
6 >
7 > A package manager that supports a better binary package format
8 > (split out local metadata would be a good start)
10 Not really a huge gain; if you're attempting remote, you're better off
11 with a single file for the entire cache anyways. If you're not doing
12 remote, the few seeks required for xpak aren't killer.
14 Granted, a cache can help, but it's design choice for the format.
15 With tbz2, you can unpack if you're completely screwed manager wise;
16 transfering binpkgs around doesn't require copying two files (as your
17 ebin format does).
20 > it's even doable with Portage's binaries, although according to a
21 > Gentoo-based distribution that tried it, your 30 minutes would be
22 > optimistic for -uDpv world...
24 Said derivative should look into adding remote binpkg v2 (solars work)
25 into portage then. The slowdown isn't due to the format, it's due to
26 the freaking craptastic implementation that snuck in.
28 Short version, remote binpkg v1 (existing in portage) is designed
29 around simply making the normal on disk repo sharable via
30 apache/ftp/whatever, no mods/transformations required; goes without
31 saying, what works for local access doesn't mean it's going to work
32 for remote. Design of it requires several roundtrips per
33 individual package lookup. It was a quick and dirty hack, and did
34 the job frankly.
36 Integrate solars caching format, the repo just becomes akin to how
37 debian/rpm distros do it- pull down a cache, operate on the cache
38 locally.
40 Fairly fast in my own playing for pkgcore.
43 > > binary-breakage protection
44 >
45 > Funnily enough... That one can be done without tree changes too via
46 > something we're calling reparenting. There're some vague suggestions of
47 > roughly how to do it at [1].
49 literal re-parenting is a grand way to make collision-protect give you
50 the finger, assuming you intend on integrating collision-protect one
51 of these days.
53 Meanwhile, kudos, portage already has this- FEATURES=preserve-libs.
54 Haven't looked to see if it's been released yet, although it's
55 been around for just over a month so no clue if it's been released yet.
56 Personally hate the feature (revdep-rebuild issues among other
57 things), but it's in.
60 Finally, regarding the weekly portage fud, probably worth noting that
61 despite the claims about "portage source being absolute crap,
62 unmodifiable", example above contradicts that bit.
64 Further...
65 * parallelization patches in bugzie
66 * long term co-exinstance of prefix branch
67 * several portage guis
68 * (surprise surprise, it uses portage)
70 all of which are created/maintained by non-portage developers
71 contradicts fair bit of BS regarding portages internals. First two
72 involve pretty heavy mods to the "unmodifiable" internals, rest are
73 demonstrations of usage of the apis, which surprisingly, isn't that
74 bad. Certainly not how I'd do it given the ability to do a
75 cleanslate, but "I prefer a different approach" doesn't automatically
76 mean "it's shite folks".
78 Part of the usual rant comes down to a long standing meme from pre
79 .51.* days; code back then *was* pretty fricking ugly in spots. I
80 used to call it "c code written in python" for example- quite a large
81 amount of refactoring since then has changed that. It ain't perfect
82 (base design forced by the legacy API for example is a core reason
83 for pkgcore even existing), but it's certainly not as bad as ciaran
84 paints it.
86 Very least, please take the time to actually dig into the
87 source and form your own opinion, instead of just accepting it as fact
88 because he repeats it damn near daily.
90 ~harring


Subject Author
Re: [gentoo-dev] [soc] Python bindings for Paludis Ciaran McCreesh <ciaranm@×××××××.org>