Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Nov 2001 10:50:02 -0800 (PST)
From:      Lauri Watts <lauri@kde.org>
To:        ports@FreeBSD.org
Subject:   Re: [kde-freebsd] Re: ports/32321: x11/kdelibs2 installs print/cups, which then causes problems
Message-ID:  <200111271850.fARIo2077468@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/32321; it has been noted by GNATS.

From: Lauri Watts <lauri@kde.org>
To: Will Andrews <will@csociety.purdue.edu>
Cc: kde-freebsd@lists.csociety.org, kde@FreeBSD.org,
	Garance A Drosihn <gad@cs.rpi.edu>, desmo@bandwidth.org,
	jah4007@cs.rit.edu, FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: [kde-freebsd] Re: ports/32321: x11/kdelibs2 installs print/cups, which then causes problems
Date: Tue, 27 Nov 2001 16:53:37 +0100

 On Tuesday 27 November 2001 14.38, you wrote:
 > On Tue, Nov 27, 2001 at 07:25:53AM -0600, David Leimbach wrote:
 
 > > Will has always been cool about my requests to have qt-designer built
 > > but IMHO it belongs as a dependency to the rest of KDE.  If you are
 
 KDevelop is not certainly part of the KDE project, but it's on a different 
 release schedule, and is normally handled quite separately.  Qt Designer 
 could ever be considered a dependency of *using* KDE.
 
 > 2) Ports should fundamentally support the use of "recommended"
 >    dependencies and not "hard" dependencies.. in packages too.
 
 This would be fabulous.  Then we wouldn't have to turn around and repeat this 
 conversation over TeTex and SDL :)
 
 > 4) KDE could remove CUPS from kdelibs dependencies.
 >
 > From my point of view, the best (perhaps not the easiest or
 > quickest) solution is #3, simply because it accounts for other
 > cases where someone might get confused because of the conflict.
 
 Best longterm.  For the shortterm, option 4 may fulfill "quick and easy" if 
 not necessarily best.
 
 For what it's worth, kdeprint does support lots of other print subsystems, 
 including lpr, LPRng and others.  
 
 There's also a configure switch to disable KDE's use of cups, even when 
 it's present on the system (  --disable-cups  if that wasn't obvious.)
 
 I've built and installed KDE many times without CUPS being installed, it's 
 never failed.  The kdeprint module still builds, without CUPS handling, and 
 it still works (I can print with the print button in KDE to whatever printer 
 I have set up locally, and I can print via kdeprint from Netscape straight 
 out to lpr too - just tell Netscape that it's print command is "kdeprint" 
 instead of lpr.)
 
 It really is very strongly recommended - KDE's printing is very much more 
 powerful with CUPS than without, and you can entirely configure CUPS from 
 within KDE's control panel, which you cannot (yet) do for lpr and friends.  
 "Strongly recommended" still doesn't equal "won't work without it" though.
 
 > > Why not just pull the KDE-CUPS dependency out and make separate ports
 > > for KDE-CUPS and the other options as a post install update?  Is this
 > > possible?
 >
 > If it's possible, I would be willing to do it.  But you'll have
 > to figure out how to do it.  :)
 
 How I'd do it:  Make one port of kdelibs with cups as a dependency, and one 
 without.  Enforce it with --disable-cups in the configure args for the 
 no-cups version, just to make sure people are getting exactly what they asked 
 for.  I'd like to suggest the default kdelibs = kde-with-cups, and make the 
 no-cups version the different one.  Naming them this way should then make it 
 obvious what's going on for admins too.
 
 Regards,
 -- 
 Lauri Watts
 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111271850.fARIo2077468>