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 w
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, Jul 28, 2005 at 09:22:56AM -0700, Donnie Berkholz wrote:
> Jason Stubbs wrote:
>
> | The reason behind this is that at approximately two thirds of bugs
> received
> | are feature requests and they are drowning at the real bugs. More
> importantly,
> | the critical bugs are becoming very ha
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... tho
On Wed, Jul 20, 2005 at 06:10:31PM -0400, Chris Gianelloni wrote:
> On Wed, 2005-07-20 at 16:54 -0500, Brian D. Harring 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
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 don't really have any input on it, aside from I'd
like to gather what peop
Clarification, mixture of the emails I haven't responded to addressed
here (further, sorry for the delay, didn't think the thread would go
any further while I was offline for birthdays/4th of july stuff)...
On Wed, Jul 06, 2005 at 04:39:14AM +0200, Martin Schlemmer wrote:
> On Tue, 2005-07-05 at
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
> >
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 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 fi
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
> > > 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 cl
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 w
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
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
> > toolcha
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
16 matches
Mail list logo
