Re: [gentoo-dev] Re: [OT] pkgcore bikeshed

[Tom Wijsman]

On Mon, 13 Jan 2014 11:02:10 +0000
"Steven J. Long" <slong@××××××××××××××××××.uk> wrote:

> Yeah but it already outshines under the hood: all you're talking
> about is EAPI and radhermit is working on it;

pkgcore's response to EAPI 6 is something to hold your breath for.

> 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.

Yes and no, in the short run I'm going to do some repoman work as to
benefit both the QA and Portage teams (and the community as a whole);
from that point on I'll try to look at Portage and pkgcore from a broad
view (software re-engineering style) to see how I want to continue.

As stated in other mails, I'll definitely help keep Portage alive for
as long as possible regardless; I will thus have to see if remaining
time permits to help out with pkgcore as well.

So, in the short run; no, also, I'm devaway for the next two weeks.

Like Portage made out a call for people, I think pkgcore should in the
near future make out a call for more people; there definitely are some
people here and there that have deep interest in it, thus contributions
to it might just be waiting around the corner...

> Updating both in parallel isn't hard: once pkgcore is up to EAPI-5,
> EAPI-6 isn't that much work (mostly bash afair.)

Its feature set is unknown afaik, thus it could become easy but just
as well become huge; this depends on the approach that the PMS team
takes going forward. But for all I know I've seen some things get
implemented in Portage, is the same true for pkgcore?

> At that point, put portage into feature-freeze, and only bugfix it.

Impossible with a new EAPI around the corner.

> Call a hiatus on new EAPIs for 6 months and put all effort into
> making damn sure pkgcore is a drop-in replacement.

This stops the progress of part of the distribution; actually, we've
stopped progress on that for quite some time already as we're already
running a bit behind on the yearly release of a new EAPI.

> > > 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.

I could indeed conclude the opposite, evening it out; it's pointless to
discuss that right now. We're currently discussing the PMs' futures;
but we're not discussing "the new package manager default" yet, neither
are we discussing a well planned proper migration yet at this time.

> > 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.

With Portage only spending half a minute* a day on it here, /care; and
as seen in benchmarks, Portage allows quite some improvements to it.
So, if needed, it is certainly possible to bring its time down.

 * --backtrack=0 is my new favorite parameter, don't need more. :)

> > [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;)

Now that I read this again:

Performance, size and compile times mean nothing if you don't get a
correct result; it all gets funny when the scrollbar of your browser
breaks just because one of its many deep dependencies was built with
-Ofast, then that small bit of extra performance can be laughed at.

<OT> And yeah, searching that dependency is also a lot of fun; which
means you'll want to recompile libraries with -O2 again until you have
found it, unless you want to spend days figuring it out. And for this
last thing, it's handy you can grep flags in the /var/db/pkg/. </OT>

<OT2> At which point you can be lucky it isn't done by some package
that has bad QA and has overridden CFLAGS or something like that. </OT2>

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D