Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)

[C. Bergström]

On 01/13/14 03:43 PM, Alexander Berntsen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 13/01/14 09:39, C. Bergström wrote:
>> Drive-by trolling comment but I wish the effort to keep porkage
>> alive would have instead been directed towards pkgcore.
> Realistically, we have to keep updating them both in parallel. pkgcore
> needs to be brought up to portage-level functionality, and we need to
> keep fixing portage bugs for its many users. We could have a technical
> discussion on the merits of pkgcore vs. portage, but in the end, it's
> about the users.
>
> 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. :-)
Where I work uses pkgcore[1], but not the areas which are generally 
beneficial to the whole community. (We use it as part of a web 
application to handle testsuites which have build dependencies.) 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)  Long term the API to pkgcore could be beneficial, but 
again I'm not sure it's a game changer for users. Dare I turn this from 
a trolling comment into a laundry list of pros/cons of pkgcore and why 
now may be a good time to invest in the future. At the end of the day we 
have one codebase which is "engineered" and another which has "evolved". 
If gentoo only ever wants to fetch tarballs and build source.. who 
cares.. If you ever want to build something on top of that - you will 
painfully realize that there's only 1 choice.

On 01/13/14 03:59 PM, Dirkjan Ochtman wrote:
> If you know your email is going to be drive-by trolling, maybe just
> hold it in next time?
Yeah I know better, but this time was like a fart - (half attempt joking)
------------


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