Date: Tue, 27 Nov 2001 05:50:03 -0800 (PST) From: Will Andrews <will@csociety.org> To: ports@FreeBSD.org Subject: Re: ports/32321: x11/kdelibs2 installs print/cups, which then causes problems Message-ID: <200111271350.fARDo3M02020@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: Will Andrews <will@csociety.org>
To: David Leimbach <leimbacd@bellsouth.net>
Cc: Will Andrews <will@csociety.purdue.edu>,
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: ports/32321: x11/kdelibs2 installs print/cups, which then causes problems
Date: Tue, 27 Nov 2001 08:38:51 -0500
On Tue, Nov 27, 2001 at 07:25:53AM -0600, David Leimbach wrote:
> Obviously CUPS isn't necessary for a functional KDE system. Will said
> so himself... its one of many options. Why then must it be installed by
> default?
It's not a strong "must", just I deemed it would be popular
enough that I'd include support for it by default (such support
has to be done at compile time, unfortunately).
> 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
> going to write KDE programs with Kdevelop [which is a part of KDE now]
> you really can benefit a whole hell of a lot by using QT-designer with
> it, especially since Kdevelop can invoke it and has no other provisions
> for running a different GUI design tool.
QT Designer doesn't belong as part of KDE. It belongs as part of
QT's development environment. I removed it because I think
people who are developers are smart enough to know they can add
QT Designer separately. I think that users who'll never use or
even know about QT Designer should be spared the pain of having
to {compile,download} the QT Designer bits.
> CUPS is different. Its one of many choices. I don't see how the fact
> that CUPS conflicts with some other print system is the CUPS
> maintainer's problem either. I mean he/she can really just say that
> only an idiot would install two print systems on the same machine and
> that the KDE port should recognize that fact and not install one by
> default.
It *IS* the CUPS maintainer's problem *and* every other port
maintainer in the tree who maintains a port with a similar
"bin/lpr" entry in their pkg-plist. Your package is supposed to
Do The Right Thing. People like the folks Garance gets
complaints from are the last people FreeBSD ports wants to
frustrate. Simply because KDE installs CUPS should not be
considered a side case because it's quite possible other ports
would want to install CUPS. So there are several solutions:
1) Ports should fundamentally support more use of "wrapper"
packages which serve only to be acted on as a dependency by
those that need some kind of system (e.g. CUPS vs. LPRng, or
Postfix vs. QMail).
2) Ports should fundamentally support the use of "recommended"
dependencies and not "hard" dependencies.. in packages too.
3) The CUPS and LPRng maintainers should work out a way to keep
their packages from conflicting should some user decide to
install both of them.
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.
> I mean who's port should take care of the only one print system rule?
> All? All but one?
Good question. See option #1 above.
> 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. :)
--
wca
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?200111271350.fARDo3M02020>