Re: ports and -current

From: Daniel Eischen <eischen_at_vigrid.com>
Date: Sun, 21 Sep 2003 00:46:30 -0400 (EDT)
On Sat, 20 Sep 2003, Doug Barton wrote:

> On Sat, 20 Sep 2003, Daniel Eischen wrote:
> 
> > On Sat, 20 Sep 2003, M. Warner Losh wrote:
> >
> > > In message: <3F6BF02F.9040707_at_schmalzbauer.de>
> > >             Harald Schmalzbauer <h_at_schmalzbauer.de> writes:
> > > : Not only the -pthread removement broke countless ports (some of them are
> > >
> > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> > > programs and not have -pthread...
> >
> > Because -pthread allows selection of one specific threadling library,
> > not multiple.  It is also unnecessary since the library is specified
> > as a link option, not a compiler option.  In the future, -pthread
> > will be a NOOP, but it suits us now to have it cause an error so
> > that ports that don't honor PTHREAD_LIBS can be found and fixed.
> 
> IF this is a good idea (and I'm not convinced it is), I still have two
> major objections to it. First, this action was taken with very little
> (any?) discussion. Second, the timing is truly horrible, occurring
> during a ports freeze.

This is the longest ports freeze that I can remember.  I wasn't
expecting it to last long.  Not to change the subject, I thought
it would just be long enough to lay the tag.  I don't think you
should label it as bad timing as much as asking why the freeze is
taking so long.

> If your goal is actually to find and fix broken ports, there are a LOT
> of other options, including enlisting volunteers, and using the package
> building cluster.
> 
> I'd really like to see this change backed out, at minimum until the
> ports freeze is over.

I'd like to see some barking up the other tree.  Why should fixes
to unbreak ports be held up by the freeze?

-- 
Dan Eischen
Received on Sat Sep 20 2003 - 19:46:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC