Gentoo Archives: gentoo-dev

From: "Steven J. Long" <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: [OT] pkgcore bikeshed
Date: Mon, 13 Jan 2014 10:50:41
In Reply to: Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) by "C. Bergström"
1 On Mon, Jan 13, 2014 at 04:15:37PM +0700, "C. Bergström" wrote:
2 > On 01/13/14 03:43 PM, Alexander Berntsen wrote:
3 > > Realistically, we have to keep updating them both in parallel. pkgcore
4 > > needs to be brought up to portage-level functionality,
6 Yeah but it already outshines under the hood: all you're talking about is
7 EAPI and radhermit is working on it; I'm sure he and dol-sen would be
8 happy for more help as well, so long as it's supportive. ISTR TomWij is
9 involved too.
11 Updating both in parallel isn't hard: once pkgcore is up to EAPI-5, EAPI-6
12 isn't that much work (mostly bash afair.) At that point, put portage into
13 feature-freeze, and only bugfix it. Call a hiatus on new EAPIs for 6 months
14 and put all effort into making damn sure pkgcore is a drop-in replacement.
16 There's certainly enough devs to do that, and definitely enough interest
17 in finally moving to portage-NG.
19 > > and we need to keep fixing portage bugs for its many users.
21 Sure.
23 > > We could have a technical
24 > > discussion on the merits of pkgcore vs. portage, but in the end, it's
25 > > about the users.
27 I don't think anyone who's serious can come down on any side but pkgcore
28 in that debate, so I agree we skip that discussion.
30 You won't get any disagreement from me on your last point.
32 > > For the record, I would be very happy if you hacked on pkgcore. Just
33 > > as happy as if you hacked on portage, even. So please do. :-)
35 Good good :-)
37 > We can blah blah about performance of resolving package dependencies
38 > all day long, but it's clearly not a game changer feature for users.
39 > (or they just don't know)
41 They just don't know: and it really is a game-changer, once you've tried it.
42 We must be able to finally deliver pkgcore speed, 5 years after the event.
44 > Long term the API to pkgcore could be beneficial, but again I'm not sure
45 > it's a game changer for users.
47 Doesn't matter: it's good to have something the devs can get hyped about too.
48 snakeoil is a lovely bit of code.
50 > [1] /* Side details */
51 > In a nutshell we make it possible to track the results of "make check"
52 > or equivalent test coverage for every source package. There's a little
53 > work involved for setting up each package, but it gives the easy ability
54 > to *know* and prove that between xyz ${FLAGS} there's no regressions.
55 > For example: How do you *know* that fftw or ssl is regression free when
56 > you enable avx, fma or some other higher level of optimization (-O3). By
57 > knowing I don't mean just result correctness, but also potentially
58 > runtime performance, code size and potentially compile times. (If those
59 > are things you care about)
61 OFC they are, or we wouldn't be using Gentoo ;) And that does sound like
62 an interesting project, of wider interest to the community. (hint hint;)
64 --
65 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


Subject Author
Re: [gentoo-dev] Re: [OT] pkgcore bikeshed Alexander Berntsen <alexander@××××××.net>
Re: [gentoo-dev] Re: [OT] pkgcore bikeshed Tom Wijsman <TomWij@g.o>
Re: [gentoo-dev] Re: [OT] pkgcore bikeshed Donnie Berkholz <dberkholz@g.o>