ports and -current

[Daniel Eischen]

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