Date: Sat, 16 Jul 2011 17:12:24 -0400 From: Jason Hellenthal <jhell@DataIX.net> To: Chris Rees <crees@freebsd.org> Cc: Stephen Montgomery-Smith <stephen@missouri.edu>, Stephen Montgomery-Smith <stephen@freebsd.org>, FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: ports/144597: security/openssh-portable fails to compile with KERBEROS enabled Message-ID: <20110716211224.GA2715@DataIX.net> In-Reply-To: <CADLo83_AsTcs8-5xaiRxyhrG_hoSwr3uD80GNVYva2pSN51Vog@mail.gmail.com> References: <4E1E72E5.10803@missouri.edu> <20110715232327.GD24288@DataIX.net> <CADLo83_AsTcs8-5xaiRxyhrG_hoSwr3uD80GNVYva2pSN51Vog@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 16, 2011 at 05:18:50PM +0100, Chris Rees wrote: > On 16 Jul 2011 00:23, "Jason Hellenthal" <jhell@dataix.net> wrote: > > > > > > > > On Wed, Jul 13, 2011 at 11:39:01PM -0500, Stephen Montgomery-Smith wrot= e: > > > Hey people, > > > > > > I was looking over old unresolved PR's. I came across this one: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/144597 > > > > > > When I sent a message to the submitter of the PR, the email bounced b= ack > > > 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 l= ike > > > there is a lot of interest. > > > > > > Thanks, Stephen > > > > > > P.S. This one is related: > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/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?=3D/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) >=20 > 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. >=20 > Otherwise we could end up with numerous bug reports because of this. >=20 > Or do everyone a favour and link them to an OPTION with extra patches! >=20 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. --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJOIf64AAoJEJBXh4mJ2FR+FOYH/27X/m3jsd88eMcP7iSWxiXe pqdO7LS5izcoG8A0dpE3NEoFn4Mlh8RYjK6su974MZA+Nxtij8GlgzSUITARnFYk pg9r54jbACILPdWLvucMeqxELdcnJDAVAd5gaYtdEB3AsRhgHcF1ZoMnXliMisAa 20RAj9uajJ3P449cMOsaCNRArPkewKTYzM3+M+iz7D+J0ae/Jj3L6HbGWq5FVU0w 4TZjJFLDIWEkCzBS3WgEZXsBmMkWGJDxSE3yi2wpka7r8LM1ypc2ganmjeGIHq8/ RAPrJo3bRcqCSeH3oV3H5VVDlIrabtnVB0AS+c1PB8ThZhWkQbyztaCPg00A5Z0= =8ecI -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110716211224.GA2715>