On Monday 13 January 2014 09:53:45 Tom Wijsman wrote:
> On Mon, 13 Jan 2014 16:15:37 +0700 "C. Bergström" wrote:
> > At the end of the day we have one codebase which is
> > "engineered" and another which has "evolved".
>
> Too broad generalization, too much assumption; both can be held as
> meanin
On Tue, 14 Jan 2014 07:22:25 +0800
Patrick Lauer wrote:
> On 01/13/2014 10:58 PM, Tom Wijsman wrote:
> > On Mon, 13 Jan 2014 10:31:56 +0100
> > Fabio Erculiani wrote:
> >
> >> Portage can still take *minutes* to calculate the merge queue of a
> >> pkg with all its deps satisfied.
> >
> > Half
On 01/13/2014 10:58 PM, Tom Wijsman wrote:
> On Mon, 13 Jan 2014 10:31:56 +0100
> Fabio Erculiani wrote:
>
>> Portage can still take *minutes* to calculate the merge queue of a
>> pkg with all its deps satisfied.
>
> Half a minute if you disable backtracking which you don't need. :)
Or if you d
On Mon, 13 Jan 2014 19:27:36 +0100
Tom Wijsman wrote:
> > Not an API. APIs are bad. What we should have is a good set of
> > lightweight Unix-friendly command line tools. See, for example, the
> > "Scripting Commands" section of "man cave".
>
> It still is an API that way, just expressed differen
On Mon, 13 Jan 2014 18:21:58 +
Ciaran McCreesh wrote:
> On Mon, 13 Jan 2014 19:16:45 +0100
> Tom Wijsman wrote:
> > On Mon, 13 Jan 2014 08:49:17 -0800
> > Alec Warner wrote:
> > > The caching may not be of use, depending on your configuration.
> > > (For example, if you use a gentoo-x86 che
On Mon, 13 Jan 2014 18:07:39 +
Ciaran McCreesh wrote:
> On Mon, 13 Jan 2014 15:46:59 +0100
> Tom Wijsman wrote:
>
> > On Mon, 13 Jan 2014 16:15:37 +0700
> > "C. Bergström" wrote:
> >
> > > Long term the API to pkgcore could be beneficial, but
> > > again I'm not sure it's a game changer
On Mon, 13 Jan 2014 19:16:45 +0100
Tom Wijsman wrote:
> On Mon, 13 Jan 2014 08:49:17 -0800
> Alec Warner wrote:
> > The caching may not be of use, depending on your configuration. (For
> > example, if you use a gentoo-x86 checkout as your main repo, you
> > will probably want to run generate cach
On Mon, 13 Jan 2014 18:05:21 +
Ciaran McCreesh wrote:
> On Mon, 13 Jan 2014 16:46:08 +0100
> Tom Wijsman wrote:
> > Rebuilds don't cause a different solution in the graph afaik; so, I
> > wouldn't see how that would form a big problem. I also think this
> > would still be covered by preserve
On Mon, 13 Jan 2014 08:49:17 -0800
Alec Warner wrote:
> The caching may not be of use, depending on your configuration. (For
> example, if you use a gentoo-x86 checkout as your main repo, you will
> probably want to run generate cache entries whenever you cvs up.) It
> is there to cache ebuild me
On Mon, 13 Jan 2014 18:03:31 +0100
Luis Ressel wrote:
> No, the problem wasn't that rebuilds weren't done (btw: this is not
> about @preserved-rebuilds, but about subslot dependencies), but that
> updates which would trigger such rebuilds are silently ignored. This
> happened to me yesterday whil
On Mon, 13 Jan 2014 15:46:59 +0100
Tom Wijsman wrote:
> On Mon, 13 Jan 2014 16:15:37 +0700
> "C. Bergström" wrote:
>
> > Long term the API to pkgcore could be beneficial, but
> > again I'm not sure it's a game changer for users.
>
> Long term, we should have an independent API backend that to
On Mon, 2014-01-13 at 15:46 +0100, Tom Wijsman wrote:
> On Mon, 13 Jan 2014 16:15:37 +0700
> "C. Bergström" wrote:
>
> > Long term the API to pkgcore could be beneficial, but
> > again I'm not sure it's a game changer for users.
>
> Long term, we should have an independent API backend that tool
On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman wrote:
> Rebuilds don't cause a different solution in the graph afaik; so, I
> wouldn't see how that would form a big problem. I also think this
> would still be covered by preserved-rebuild and/or revdep-rebuild
> afterwards.
There used to be a "fea
On Tue, Jan 14, 2014 at 12:42:00AM +0700, "C. Bergström" wrote:
> On 01/14/14 12:37 AM, Greg KH wrote:
> >On Mon, Jan 13, 2014 at 04:15:37PM +0700, "C. Bergström" wrote:
> >>At the end of the day we have one codebase which is "engineered" and
> >>another which has "evolved".
> >I'll take an "evolve
> On Mon, 13 Jan 2014, Tom Wijsman wrote:
>> I've started collecting things already some months ago:
>> http://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features
> Just for reference: https://bugs.gentoo.org/show_bug.cgi?id=174380
> According to [1] there are besides the tracker a 78
On Mon, Jan 13, 2014 at 04:15:37PM +0700, "C. Bergström" wrote:
> At the end of the day we have one codebase which is "engineered" and
> another which has "evolved".
I'll take an "evolved" codebase over "engineered" anyday.
You do realize that is exactly why Linux has succeeded, right? The
kerne
On 01/14/14 12:37 AM, Greg KH wrote:
On Mon, Jan 13, 2014 at 04:15:37PM +0700, "C. Bergström" wrote:
At the end of the day we have one codebase which is "engineered" and
another which has "evolved".
I'll take an "evolved" codebase over "engineered" anyday.
You do realize that is exactly why Li
On Mon, Jan 13, 2014 at 5:49 PM, Alec Warner wrote:
[...]
>
> This is not meant to imply that portage is always fast; there are plenty of
> other modules (such as the aforementioned backtracking) that can take a long
> time to find solutions. That is partially why you see Tomwij turning off
> that
On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman wrote:
> On Mon, 13 Jan 2014 16:38:59 +0100
> Luis Ressel wrote:
>
> > On Mon, 13 Jan 2014 15:58:13 +0100
> > Tom Wijsman wrote:
> >
> > > Half a minute if you disable backtracking which you don't need. :)
> >
> > Which sadly also means that som
On Mon, Jan 13, 2014 at 7:38 AM, Luis Ressel wrote:
> On Mon, 13 Jan 2014 15:58:13 +0100
> Tom Wijsman wrote:
>
> > On Mon, 13 Jan 2014 10:31:56 +0100
> > Fabio Erculiani wrote:
> >
> > > Portage can still take *minutes* to calculate the merge queue of a
> > > pkg with all its deps satisfied.
>
On Mon, 13 Jan 2014 16:38:59 +0100
Luis Ressel wrote:
> On Mon, 13 Jan 2014 15:58:13 +0100
> Tom Wijsman wrote:
>
> > Half a minute if you disable backtracking which you don't need. :)
>
> Which sadly also means that some updates get skipped silently. (Those
> which would trigger rebuilds of o
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman wrote:
> On Mon, 13 Jan 2014 10:31:56 +0100
> Fabio Erculiani wrote:
>
> > Portage can still take *minutes* to calculate the merge queue of a
> > pkg with all its deps satisfied.
>
> Half a minute if you disable backtracking which you don't need.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 13 Jan 2014 09:56:13 -0500
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 13/01/14 09:46 AM, Tom Wijsman wrote:
> > On Mon, 13 Jan 2014 16:15:37 +0700 "C. Bergström"
> > wrote:
> >
> >> Long term the API
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani wrote:
> Portage can still take *minutes* to calculate the merge queue of a
> pkg with all its deps satisfied.
Half a minute if you disable backtracking which you don't need. :)
> Ironically, launching the same emerge command twice, will take m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/01/14 09:46 AM, Tom Wijsman wrote:
> On Mon, 13 Jan 2014 16:15:37 +0700 "C. Bergström"
> wrote:
>
>> Long term the API to pkgcore could be beneficial, but again I'm
>> not sure it's a game changer for users.
>
> Long term, we should have an
On Mon, 13 Jan 2014 16:15:37 +0700
"C. Bergström" wrote:
> At the end of the day we have one codebase which is
> "engineered" and another which has "evolved".
Too broad generalization, too much assumption; both can be held as
meaning nothing compared to what "engineered" and "evolved" could
real
On Mon, 13 Jan 2014 16:15:37 +0700
"C. Bergström" wrote:
> Long term the API to pkgcore could be beneficial, but
> again I'm not sure it's a game changer for users.
Long term, we should have an independent API backend that tools can
query; not rewrite our tools every time users want to use them
On 01/13/14 04:31 PM, Fabio Erculiani wrote:
On Mon, Jan 13, 2014 at 10:15 AM, "C. Bergström"
wrote:
On 01/13/14 03:43 PM, Alexander Berntsen wrote:
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
On Mon, Jan 13, 2014 at 10:15 AM, "C. Bergström"
wrote:
> On 01/13/14 03:43 PM, Alexander Berntsen wrote:
> 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 depen
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
30 matches
Mail list logo
