Long one kiddies... responses inlined, bit more interested in
discussion of what's required/desired then your definition of
enterprise sucks... (throws on the flamesuit)...
On Thu, Aug 04, 2005 at 02:35:08PM -0400, Chris Gianelloni wrote:
On Thu, 2005-08-04 at 11:48 -0400, Eric Brown wrote:
On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote:
The only things I could see being needed out of portage itself is the
ability to control emerge commands remotely, such as forcing an update
of apache to $version to resolve a vulnerability.
The requirements of portage, or
On Sat, Jul 23, 2005 at 01:20:19AM +0200, Sven Köhler wrote:
Out of curiousity, has any put any thought into some automated method
or hook for allowing restarting of rc-scripts on upgrade/re-emerge of
a package?
Other question is if any such hook is even needed.
So... thoughts? I
On Fri, Jul 01, 2005 at 08:16:46PM -0500, Kito wrote:
Accurate deps should be a goal for the tree, a long term one
obviously...
Picking at the words (not you), but long term == it gets ignored
till someone starts screaming/foaming at the mouth.
If BDEPEND were added, it's extra data that
On Sat, Jul 02, 2005 at 01:43:43PM +0200, foser wrote:
On Fri, 2005-07-01 at 18:33 +0300, Dan Armak wrote:
calling a function in a global scope is a bad idea. it leads to lots of
unneccessary (and timely) computations
Necessary in the case of kde split ebuilds. Take a look at
Hola.
Quick statement of terminology-
x-compile == cross compiling, building arm crap on an x86, building up
a x-compile target in a subdirectory of / (fex)
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
On Fri, Jul 01, 2005 at 01:49:19PM -0400, Mike Frysinger wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
toolchain. Couple of issues
On Fri, Jul 01, 2005 at 02:30:12PM -0400, Mike Frysinger wrote:
On Friday 01 July 2005 02:11 pm, Brian D. Harring wrote:
Meanwhile, back to the you want us to add what?, our dependency
graph *is* incomplete.
so what ? i dont see it being a bug
I do. :)
We do a lot of work to have deps
On Fri, Jul 01, 2005 at 08:35:36PM +0200, Maurice van der Pot wrote:
If the point is to make dependencies complete, isn't there a way to
build in some support for detecting it into some tool or other?
If we have a program that can create an environment and detect which
programs are run
Full dependency information hasn't be viable due to resolver issues,
which will be fixed.
so why dont you come back once you have something that is supposed to work
?
you're proposing we start generating a ton of circular dependencies which
we
arent even close to handling
On Fri, Jul 01, 2005 at 08:53:18PM +0200, Diego 'Flameeyes' Pettenò wrote:
On Friday 01 July 2005 20:42, Brian D. Harring wrote:
Err... missing the point, and proving my point. Current portage
_will_ fail because it's an unstated dependency. Why shouldn't
portage be provided the deps
On Fri, Jul 01, 2005 at 08:56:45PM +0200, Maurice van der Pot wrote:
On Fri, Jul 01, 2005 at 01:45:20PM -0500, Brian D. Harring wrote:
Not tenuable
What you're effectivelly suggesting is that portage stomp ahead and,
hit a failure, try and figure out what atom would fix the failure
Hola.
Quick statement of terminology-
x-compile == cross compiling, building arm crap on an x86, building up
a x-compile target in a subdirectory of / (fex)
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
13 matches
Mail list logo
