On Sun, May 27, 2007 at 10:51:56PM -0400, Mike Meyer wrote:
> In <[EMAIL PROTECTED]>, Edwin Groothuis <[EMAIL PROTECTED]> typed:
> > On Sun, May 27, 2007 at 08:44:56PM -0500, Mark Linimon wrote:
> > > In summary, the ports infrastructure is really complicated because it's
> > > trying to deal with
In <[EMAIL PROTECTED]>, Edwin Groothuis <[EMAIL PROTECTED]> typed:
> On Sun, May 27, 2007 at 08:44:56PM -0500, Mark Linimon wrote:
> > In summary, the ports infrastructure is really complicated because it's
> > trying to deal with all kinds of constraints and conditions. I challenge
> Reading this
On Mon, May 28, 2007 at 12:15:28AM +0200, Michel Talon wrote:
> To gain some performance, a first idea would be to simplify
> bsd.ports.mk. I am convinced that a substantial part of the 4000 lines
> are historical crap which serve no useful purpose.
11272 of LOC in bsd.*.mk, but who's counting.
>
On Sun, May 27, 2007 at 08:44:56PM -0500, Mark Linimon wrote:
> In summary, the ports infrastructure is really complicated because it's
> trying to deal with all kinds of constraints and conditions. I challenge
Reading this, I was wondering what the ports infrastructure has
ever done for us?
See
I'm looking for something that will work with the existing framework.
But yes, I get the feeling that maybe using "make" to process the ports
might be the source of the problem. Make is a program primarily
designed for figuring out which was made first, the target or the
source, but in the por
Jeremy Chadwick wrote:
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for "make
index" and pkg_version and things like that. So for example, in
pkg_version, it calls "make -V PKGNAME" for every installed
On Mon, 28 May 2007, Michel Talon wrote:
Stephen Montgomery-Smith said:
I suggest rewriting "make" so that variables are only evaluated on a
"need to know" basis.
or "I have tried to do this."
Of course a lot of people have thinked about it, and quickly realized
that it was not going
Stephen Montgomery-Smith said:
> I suggest rewriting "make" so that variables are only evaluated on a
> "need to know" basis.
> or "I have tried to do this."
Of course a lot of people have thinked about it, and quickly realized
that it was not going to work. In the bsd.ports.mk, evaluation
Not quite what you asked for but...
Given the size and complexity of the port system I have long
felt that rather than do everything via more and more complex
Mk/*.mk what is is needed is a ports server and a thin CLI
frontend to it.
This server can store dependency data in an efficient manner,
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
> I have been thinking a lot about looking for speed increases for "make
> index" and pkg_version and things like that. So for example, in
> pkg_version, it calls "make -V PKGNAME" for every installed package. Now
> "
I have been thinking a lot about looking for speed increases for "make
index" and pkg_version and things like that. So for example, in
pkg_version, it calls "make -V PKGNAME" for every installed package.
Now "make -V PKGNAME" should be a speedy operation, but the make has to
load in and analyz
On 27/05/07, Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote:
Having a generic, more secure and reliable (local) logging mechnism
should be discussed in at least another thread. You may as well think
of taking this idea to IETF as RFC 3164 lives there as a Memo these
days and it might be a general enou
On Sun, 27 May 2007, Benjamin Lutz wrote:
Hi,
[ log shippping daemon for audit and other other logs ]
[ syslog problems ]
sorry I have to cut this short;)
What Alexey said - this will be about log shipping not about writing
single log records etc.
Your syslog problems are outside the scope o
On Saturday 26 May 2007 09:49, Alexey Mikhailov wrote:
> On Friday 25 May 2007 22:04:34 Benjamin Lutz wrote:
> > On Friday 25 May 2007 01:22:21 Alexey Mikhailov wrote:
> > > [...]
> > > 2. As I said before initial subject of this project was
> > > "Distributed audit daemon". But after some discussi
14 matches
Mail list logo
