How to handle upgrade of libnotify when cups-client-1.4.8 is marked as broken

[Kostik Belousov]

On Sun, Aug 28, 2011 at 07:41:20PM +0100, Chris Rees wrote:
> On 28 August 2011 19:33, Kostik Belousov <kostikbel at gmail.com> wrote:
> > On Sun, Aug 28, 2011 at 02:13:59PM -0400, Sahil Tandon wrote:
> >> On Sun, 2011-08-28 at 20:30:59 +0300, Kostik Belousov wrote:
> >>
> >> > On Sun, Aug 28, 2011 at 01:26:51PM -0400, Sahil Tandon wrote:
> >> > > On Sun, 2011-08-28 at 11:30:27 -0400, Carmel wrote:
> >> > >
> >> > > > My question is what changed? It worked before updating "libnotify". Is
> >> > > > "libnotify" the culprit or "GNUTLS" or something else and why didn't
> >> > > > anyone catch this problem sooner?
> >> > >
> >> > > The chain of dependencies during the libnotify update prompted the
> >> > > upgrade of cups.  The latter's OpenSSL interfaces are explicitly
> >> > > thread-safe, which GNU TLS is not.
> >> > >
> >> > > > There appears to be a lot of material released lately that is either
> >> > > > broken or requiring a considerable amount of manual intervention.
> >> > > > Perhaps a moratorium (port freeze) should be considered until all of
> >> > > > the outstanding problems have been corrected.
> >> > >
> >> > > We are sorry for the inconvenience which is surely frustrating, but
> >> > > freezing the tree because of this does not seem appropriate.
> >> >
> >> > Might be, completely ignoring the option 'use gnutls' in cups ports,
> >> > until it can be made working, will change everybody life to be easier.
> >>
> >> What "might be"?
> >>
> >> As already noted, the GNUTLS option now defaults to OFF and users are
> >> warned (via the BROKEN construct) if it is selected.
> >
> > Apparently, this have to be written explicitely. Users, who upgrade
> > their ports, are not presented with the configuration dialog. Using
> > automated tool like portupgrade, all you get is a list of the failed
> > ports. After that, user needs to start investigation, spending his
> > own time and possibly time of the people on list.
> >
> > Ignoring or removing the option makes the ports upgrade without user
> > intervention.
> >
> > I am willing to spend some more time describing unobvious points of
> > this consideration.
> 
> Alright, how about this?
> 
> RCS file: /home/pcvs/ports/print/cups-base/Makefile,v
> retrieving revision 1.162
> diff -u -r1.162 Makefile
> --- Makefile	25 Aug 2011 14:54:39 -0000	1.162
> +++ Makefile	28 Aug 2011 18:40:24 -0000
> @@ -124,7 +124,7 @@
>  .endif
> 
>  .if defined(WITH_GNUTLS)
> -BROKEN=			gnutls does not support threads yet
> +BROKEN=		gnutls does not support threads yet; disable the GNUTLS
> option to build
>  CONFIGURE_ARGS+=	--disable-openssl --enable-gnutls
>  CONFIGURE_ENV+=		PKGCONFIG="${LOCALBASE}/bin/pkg-config"
>  LIB_DEPENDS+=		gnutls-openssl.27:${PORTSDIR}/security/gnutls
> 
> Dirk, do you have any objections if I were to commit that?

It still requires manual intervention into the process which can be automated.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20110828/a7b69b12/attachment.pgp