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 |