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
meaning nothing
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
On Mon, Jan 13, 2014 at 10:15 AM, C. Bergström
cbergst...@pathscale.com 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
On 01/13/14 04:31 PM, Fabio Erculiani wrote:
On Mon, Jan 13, 2014 at 10:15 AM, C. Bergström
cbergst...@pathscale.com 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
On Mon, 13 Jan 2014 16:15:37 +0700
C. Bergström cbergst...@pathscale.com 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
On Mon, 13 Jan 2014 16:15:37 +0700
C. Bergström cbergst...@pathscale.com 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
-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
cbergst...@pathscale.com 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
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani lx...@gentoo.org 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 13 Jan 2014 09:56:13 -0500
Ian Stakenvicius a...@gentoo.org 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
cbergst...@pathscale.com
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani lx...@gentoo.org 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
On Mon, 13 Jan 2014 16:38:59 +0100
Luis Ressel ara...@aixah.de wrote:
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman tom...@gentoo.org 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
On Mon, Jan 13, 2014 at 7:38 AM, Luis Ressel ara...@aixah.de wrote:
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani lx...@gentoo.org wrote:
Portage can still take *minutes* to calculate the merge queue of a
On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 16:38:59 +0100
Luis Ressel ara...@aixah.de wrote:
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman tom...@gentoo.org wrote:
Half a minute if you disable backtracking which you don't need. :)
On Mon, Jan 13, 2014 at 5:49 PM, Alec Warner anta...@gentoo.org 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
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
kernel has
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 evolved codebase over
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 Linux has
On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman tom...@gentoo.org 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
On Mon, 2014-01-13 at 15:46 +0100, Tom Wijsman wrote:
On Mon, 13 Jan 2014 16:15:37 +0700
C. Bergström cbergst...@pathscale.com 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
On Mon, 13 Jan 2014 15:46:59 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 16:15:37 +0700
C. Bergström cbergst...@pathscale.com 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 18:03:31 +0100
Luis Ressel ara...@aixah.de 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
On Mon, 13 Jan 2014 08:49:17 -0800
Alec Warner anta...@gentoo.org 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
On Mon, 13 Jan 2014 18:05:21 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman tom...@gentoo.org 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
On Mon, 13 Jan 2014 19:16:45 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 08:49:17 -0800
Alec Warner anta...@gentoo.org 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
On Mon, 13 Jan 2014 18:07:39 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 13 Jan 2014 15:46:59 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 16:15:37 +0700
C. Bergström cbergst...@pathscale.com wrote:
Long term the API to pkgcore could be
On Mon, 13 Jan 2014 18:21:58 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 13 Jan 2014 19:16:45 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 08:49:17 -0800
Alec Warner anta...@gentoo.org wrote:
The caching may not be of use, depending on your
On Mon, 13 Jan 2014 19:27:36 +0100
Tom Wijsman tom...@gentoo.org 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
On 01/13/2014 10:58 PM, Tom Wijsman wrote:
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani lx...@gentoo.org 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
On Tue, 14 Jan 2014 07:22:25 +0800
Patrick Lauer patr...@gentoo.org wrote:
On 01/13/2014 10:58 PM, Tom Wijsman wrote:
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani lx...@gentoo.org wrote:
Portage can still take *minutes* to calculate the merge queue of a
pkg with all its deps
29 matches
Mail list logo
