Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaranm@×××××××.org>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [soc] Python bindings for Paludis
Date: Fri, 30 Mar 2007 13:20:48
Message-Id: 20070330141801.260afdc8@snowflake
In Reply to: Re: [gentoo-dev] [soc] Python bindings for Paludis by Brian Harring
1 On Fri, 30 Mar 2007 02:07:33 -0700
2 Brian Harring <ferringb@×××××.com> wrote:
3 > On Thu, Mar 29, 2007 at 10:04:57PM +0100, Ciaran McCreesh wrote:
4 > > On Thu, 29 Mar 2007 22:47:46 +0200
5 > > Thomas Rösner <Thomas.Roesner@××××××××××××××.de> wrote:
6 > > > Other things I want from Gentoo right now depend on factors other
7 > > > than the package manager, too; prebuilt packages
8 > >
9 > > A package manager that supports a better binary package format
10 > > (split out local metadata would be a good start)
11 >
12 > Not really a huge gain; if you're attempting remote, you're better
13 > off with a single file for the entire cache anyways. If you're not
14 > doing remote, the few seeks required for xpak aren't killer.
15
16 *shrug* I was thinking local or fast-access to metadata, remote and
17 potentially slow binaries, personally. There are several viable ways of
18 doing it.
19
20 From benchmarking, a single file cache tends to end up being slower
21 than multiple files for operations that don't involve inspecting most
22 of the tree. It's not a huge issue, and the difference is tiny in
23 comparison to the way Portage does things currently...
24
25 > > > binary-breakage protection
26 > >
27 > > Funnily enough... That one can be done without tree changes too via
28 > > something we're calling reparenting. There're some vague
29 > > suggestions of roughly how to do it at [1].
30 >
31 > literal re-parenting is a grand way to make collision-protect give
32 > you the finger
33
34 Well yes, but no-one sane is talking about literal reparenting, because
35 there are far better solutions that're almost as easy to implement.
36
37 > assuming you intend on integrating collision-protect one of these
38 > days.
39
40 Hm? No-one's found it interesting or useful enough to ship it as core
41 with Paludis. It's available as a third party hook for anyone who wants
42 it...
43
44 > Meanwhile, kudos, portage already has this- FEATURES=preserve-libs.
45 > Haven't looked to see if it's been released yet, although it's
46 > been around for just over a month so no clue if it's been released
47 > yet. Personally hate the feature (revdep-rebuild issues among other
48 > things), but it's in.
49
50 We're talking about doing it properly, as you know all too well...
51
52 > Finally, regarding the weekly portage fud, probably worth noting that
53 > despite the claims about "portage source being absolute crap,
54 > unmodifiable", example above contradicts that bit.
55 >
56 > Further...
57 > * parallelization patches in bugzie
58 > * long term co-exinstance of prefix branch
59 > * several portage guis
60 > * packages.gentoo.org (surprise surprise, it uses portage)
61 >
62 > all of which are created/maintained by non-portage developers
63 > contradicts fair bit of BS regarding portages internals.
64
65 And think what there would be if Portage had a decent API and
66 internals...
67
68 > Part of the usual rant comes down to a long standing meme from pre
69 > .51.* days; code back then *was* pretty fricking ugly in spots. I
70 > used to call it "c code written in python" for example- quite a large
71 > amount of refactoring since then has changed that. It ain't perfect
72 > (base design forced by the legacy API for example is a core reason
73 > for pkgcore even existing), but it's certainly not as bad as ciaran
74 > paints it.
75
76 Better than it was is hardly a glowing commendation... I'd use the well
77 known technical description involving polishing here, but someone would
78 just pretend that it's offensive...
79
80 --
81 Ciaran McCreesh

Attachments

File name MIME type
signature.asc application/pgp-signature