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)
