| 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, |
| 5 |
|
| 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. |
| 10 |
|
| 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. |
| 15 |
|
| 16 |
There's certainly enough devs to do that, and definitely enough interest |
| 17 |
in finally moving to portage-NG. |
| 18 |
|
| 19 |
> > and we need to keep fixing portage bugs for its many users. |
| 20 |
|
| 21 |
Sure. |
| 22 |
|
| 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. |
| 26 |
|
| 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. |
| 29 |
|
| 30 |
You won't get any disagreement from me on your last point. |
| 31 |
|
| 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. :-) |
| 34 |
|
| 35 |
Good good :-) |
| 36 |
|
| 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) |
| 40 |
|
| 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. |
| 43 |
|
| 44 |
> Long term the API to pkgcore could be beneficial, but again I'm not sure |
| 45 |
> it's a game changer for users. |
| 46 |
|
| 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. |
| 49 |
|
| 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) |
| 60 |
|
| 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;) |
| 63 |
|
| 64 |
-- |
| 65 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives