Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: slong@××××××××××××××××××.uk
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [OT] pkgcore bikeshed
Date: Mon, 13 Jan 2014 15:22:55
Message-Id: 20140113162149.4f955b87@TOMWIJ-GENTOO
In Reply to: [gentoo-dev] Re: [OT] pkgcore bikeshed by "Steven J. Long"
1 On Mon, 13 Jan 2014 11:02:10 +0000
2 "Steven J. Long" <slong@××××××××××××××××××.uk> wrote:
4 > Yeah but it already outshines under the hood: all you're talking
5 > about is EAPI and radhermit is working on it;
7 pkgcore's response to EAPI 6 is something to hold your breath for.
9 > I'm sure he and dol-sen would be happy for more help as well, so long
10 > as it's supportive. ISTR TomWij is involved too.
12 Yes and no, in the short run I'm going to do some repoman work as to
13 benefit both the QA and Portage teams (and the community as a whole);
14 from that point on I'll try to look at Portage and pkgcore from a broad
15 view (software re-engineering style) to see how I want to continue.
17 As stated in other mails, I'll definitely help keep Portage alive for
18 as long as possible regardless; I will thus have to see if remaining
19 time permits to help out with pkgcore as well.
21 So, in the short run; no, also, I'm devaway for the next two weeks.
23 Like Portage made out a call for people, I think pkgcore should in the
24 near future make out a call for more people; there definitely are some
25 people here and there that have deep interest in it, thus contributions
26 to it might just be waiting around the corner...
28 > Updating both in parallel isn't hard: once pkgcore is up to EAPI-5,
29 > EAPI-6 isn't that much work (mostly bash afair.)
31 Its feature set is unknown afaik, thus it could become easy but just
32 as well become huge; this depends on the approach that the PMS team
33 takes going forward. But for all I know I've seen some things get
34 implemented in Portage, is the same true for pkgcore?
36 > At that point, put portage into feature-freeze, and only bugfix it.
38 Impossible with a new EAPI around the corner.
40 > Call a hiatus on new EAPIs for 6 months and put all effort into
41 > making damn sure pkgcore is a drop-in replacement.
43 This stops the progress of part of the distribution; actually, we've
44 stopped progress on that for quite some time already as we're already
45 running a bit behind on the yearly release of a new EAPI.
47 > > > We could have a technical
48 > > > discussion on the merits of pkgcore vs. portage, but in the end,
49 > > > it's about the users.
50 >
51 > I don't think anyone who's serious can come down on any side but
52 > pkgcore in that debate, so I agree we skip that discussion.
54 I could indeed conclude the opposite, evening it out; it's pointless to
55 discuss that right now. We're currently discussing the PMs' futures;
56 but we're not discussing "the new package manager default" yet, neither
57 are we discussing a well planned proper migration yet at this time.
59 > > We can blah blah about performance of resolving package dependencies
60 > > all day long, but it's clearly not a game changer feature for users.
61 > > (or they just don't know)
62 >
63 > They just don't know: and it really is a game-changer, once you've
64 > tried it. We must be able to finally deliver pkgcore speed, 5 years
65 > after the event.
67 With Portage only spending half a minute* a day on it here, /care; and
68 as seen in benchmarks, Portage allows quite some improvements to it.
69 So, if needed, it is certainly possible to bring its time down.
71 * --backtrack=0 is my new favorite parameter, don't need more. :)
73 > > [1] /* Side details */
74 > > In a nutshell we make it possible to track the results of "make
75 > > check" or equivalent test coverage for every source package.
76 > > There's a little work involved for setting up each package, but it
77 > > gives the easy ability to *know* and prove that between xyz
78 > > ${FLAGS} there's no regressions. For example: How do you *know*
79 > > that fftw or ssl is regression free when you enable avx, fma or
80 > > some other higher level of optimization (-O3). By knowing I don't
81 > > mean just result correctness, but also potentially runtime
82 > > performance, code size and potentially compile times. (If those are
83 > > things you care about)
84 >
85 > OFC they are, or we wouldn't be using Gentoo ;) And that does sound
86 > like an interesting project, of wider interest to the community.
87 > (hint hint;)
89 Now that I read this again:
91 Performance, size and compile times mean nothing if you don't get a
92 correct result; it all gets funny when the scrollbar of your browser
93 breaks just because one of its many deep dependencies was built with
94 -Ofast, then that small bit of extra performance can be laughed at.
96 <OT> And yeah, searching that dependency is also a lot of fun; which
97 means you'll want to recompile libraries with -O2 again until you have
98 found it, unless you want to spend days figuring it out. And for this
99 last thing, it's handy you can grep flags in the /var/db/pkg/. </OT>
101 <OT2> At which point you can be lucky it isn't done by some package
102 that has bad QA and has overridden CFLAGS or something like that. </OT2>
104 --
105 With kind regards,
107 Tom Wijsman (TomWij)
108 Gentoo Developer
110 E-mail address : TomWij@g.o
111 GPG Public Key : 6D34E57D
112 GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D


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