Gentoo Archives: gentoo-dev

From: "C. Bergström" <cbergstrom@×××××××××.com>
To: gentoo-dev@l.g.o
Cc: Alexander Berntsen <alexander@××××××.net>
Subject: Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)
Date: Mon, 13 Jan 2014 09:17:53
In Reply to: Re: [gentoo-dev] Portage team, Zac's development break and stepping down as lead by Alexander Berntsen
1 On 01/13/14 03:43 PM, Alexander Berntsen wrote:
3 > Hash: SHA256
4 >
5 > On 13/01/14 09:39, C. Bergström wrote:
6 >> Drive-by trolling comment but I wish the effort to keep porkage
7 >> alive would have instead been directed towards pkgcore.
8 > Realistically, we have to keep updating them both in parallel. pkgcore
9 > needs to be brought up to portage-level functionality, and we need to
10 > keep fixing portage bugs for its many users. We could have a technical
11 > discussion on the merits of pkgcore vs. portage, but in the end, it's
12 > about the users.
13 >
14 > For the record, I would be very happy if you hacked on pkgcore. Just
15 > as happy as if you hacked on portage, even. So please do. :-)
16 Where I work uses pkgcore[1], but not the areas which are generally
17 beneficial to the whole community. (We use it as part of a web
18 application to handle testsuites which have build dependencies.) We can
19 blah blah about performance of resolving package dependencies all day
20 long, but it's clearly not a game changer feature for users. (or they
21 just don't know) Long term the API to pkgcore could be beneficial, but
22 again I'm not sure it's a game changer for users. Dare I turn this from
23 a trolling comment into a laundry list of pros/cons of pkgcore and why
24 now may be a good time to invest in the future. At the end of the day we
25 have one codebase which is "engineered" and another which has "evolved".
26 If gentoo only ever wants to fetch tarballs and build source.. who
27 cares.. If you ever want to build something on top of that - you will
28 painfully realize that there's only 1 choice.
30 On 01/13/14 03:59 PM, Dirkjan Ochtman wrote:
31 > If you know your email is going to be drive-by trolling, maybe just
32 > hold it in next time?
33 Yeah I know better, but this time was like a fart - (half attempt joking)
34 ------------
37 [1] /* Side details */
38 In a nutshell we make it possible to track the results of "make check"
39 or equivalent test coverage for every source package. There's a little
40 work involved for setting up each package, but it gives the easy ability
41 to *know* and prove that between xyz ${FLAGS} there's no regressions.
42 For example: How do you *know* that fftw or ssl is regression free when
43 you enable avx, fma or some other higher level of optimization (-O3). By
44 knowing I don't mean just result correctness, but also potentially
45 runtime performance, code size and potentially compile times. (If those
46 are things you care about)


Subject Author
Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) Fabio Erculiani <lxnay@g.o>
[gentoo-dev] Re: [OT] pkgcore bikeshed "Steven J. Long" <slong@××××××××××××××××××.uk>
Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) Tom Wijsman <TomWij@g.o>
Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) Tom Wijsman <TomWij@g.o>
Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) Greg KH <gregkh@g.o>