ports/144597: security/openssh-portable fails to compile with KERBEROS enabled

[Jason Hellenthal]

On Sat, Jul 16, 2011 at 05:18:50PM +0100, Chris Rees wrote:
> On 16 Jul 2011 00:23, "Jason Hellenthal" <jhell at dataix.net> wrote:
> >
> >
> >
> > On Wed, Jul 13, 2011 at 11:39:01PM -0500, Stephen Montgomery-Smith wrote:
> > > Hey people,
> > >
> > > I was looking over old unresolved PR's.  I came across this one:
> > >
> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144597
> > >
> > > When I sent a message to the submitter of the PR, the email bounced back
> > > suggesting that the submitter no longer uses that email address.
> > >
> > > I don't think it would be too hard to make the port build under the
> > > circumstances he describes.  But is ANYONE interested?  Would it be
> > > worth investing effort to make this work?
> > >
> > > Note that the port has ports@ as its maintainer, so it doesn't look like
> > > there is a lot of interest.
> > >
> > > Thanks, Stephen
> > >
> > > P.S. This one is related:
> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/57498
> > >
> > > Is this a big bag of worms?
> > >
> > > I can see that seems to be fixed, for example, in mail/fetchmail.
> >
> > Considering that the port version is 5.2p1 and the current version in
> > stable/8 is 5.4p1 and greater than that for HEAD I would say it would be
> > much more of a benefit to get the port updated to the latest version and
> > then work on it from there, otherwise its a loss of time for an outdated
> > version.
> >
> > Last time I looked at this port it was a mess with a collection of third
> > party patches from all over the place which I think lead to a
> > discrepancy in the update of the port but that's just my opinion. It
> > would be nice to see a simplified version of this port so it isn't such a
> > monster to update and have an option for a user supplied patches
> > directory that stands outside of the tree (user configured path) and it
> > just blindly attempts to apply what is in that directory. I think this
> > would help slim it down a little so it can consistently be bumped to a
> > new revision without hassle.
> >
> >
> > Something like:
> >
> > # Defaults to /usr/ports/patches unless path is user specified.
> > WITH_PATCH_TREE?=/usr/ports/patches
> >
> > /usr/ports/patches/ # Distributed empty. everything else user created.
> > |-- net
> > |   `-- wireshark
> > `-- security
> >    |-- gnupg
> >    `-- openssh-portable
> >
> >
> > Things like this would certainly make it easier for a consistent user
> > supplied patch to be kept local for build machines. I can't count the
> > times on 2 hands and 2 feet that I wanted to patch a port with a local
> > patch and had to continuously cp(1) a patch back to a ports tree using
> > rsync(1)
> 
> Not really, because that would encourage people to have local patches that
> quickly go stale. You should have to manually record the patches, because
> you should be checking they're still current each time.
> 
> Otherwise we could end up with numerous bug reports because of this.
> 
> Or do everyone a favour and link them to an OPTION with extra patches!
> 

This is purely user-side. If a user is advanced enough to use the ports
tree more or less figure out how to use patches with it then I would
think they are bright enough to figure out it is their problem and not
ports. Besides if a patch fails to apply a warning message could point
the user directly to their patch... its not that hard.

We should not be trying to govern the inteligence of the end user, but
instead provide them with ability to expand. This is seriously one of
the things that the ports tree lacks even with the options framework
that is considerably a failure prone mixture between distributed
packages & user installed ports which can be observed over and over
again, so the same can be said about the options framework as my idea
stated above.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20110716/a65f8fd0/attachment.pgp