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