From owner-freebsd-questions Mon Nov 26 2:22:35 2001 Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (okc-65-31-203-60.mmcable.com [65.31.203.60]) by hub.freebsd.org (Postfix) with SMTP id 32C9937B419 for ; Mon, 26 Nov 2001 02:22:30 -0800 (PST) Received: (qmail 38964 invoked by uid 100); 26 Nov 2001 10:22:29 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15362.6117.389492.58321@guru.mired.org> Date: Mon, 26 Nov 2001 04:22:29 -0600 To: Simon J Mudd Cc: questions@freebsd.org Subject: Re: gv port builds but fails - needing libpng.so.4 (?) In-Reply-To: <74296747@toto.iv> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Simon J Mudd types: > On Sun, 25 Nov 2001, Kris Kennaway wrote: > > I bet gv is actually fine, but the problem is actually with the > > ghostscript port which is used to do the actual PS rendering. > > ghostscript uses png. > I think my point is this: > - why isn't this enforced by the ports collection? It mostly is. Somewhere along the way you deleted the old libpng. If you used the package routines, you had to tell it "-f" to make it do so. If you used ports, it warned you about the dependencies when you did the "make deinstall" so you could deal with them as required. > - why is it currenlty allowed Because sometimes it does no harm, so there's no point in forcing people to rebuild ports that don't need it. This is the general Unix philosophy: give the user all the rope they need to do the job. That's far more than enough for them to hang themselves. Some systems consider that a problem, but Unix isn't one of them. > - why do the ports collection allow you to have two "conflicting" ports > installed at the same time Because there are times when you want to do that. It can even be done safely if you install to different locations. See the paragraph on the Unix philosophy above. > - this really causes the problem I've encountered. Having two copies installed wasn't the root of the problem. Removing one and ignoring the warnings about dependencies was the problem. Before claiming that it shouldn't allow that, see the paragraph otUP. > - ideally you shouldn't be allowed to uninstall/upgrade a port > on which other ports depend, unless as you say you upgrade the > dependent ports too. I think this information should be available > at make install or make deinstall time. No, no, a thousand times no. A port upgrade may be a port revision, meaning the application source code hasn't changed, but the port author tweaked something for some reason - for instance, making the port PREFIX-clean. There's no reason to upgrade everything it depends on in that case. Even if the application port code changed, if files in the port are used by but not built into the dependent application, the dependent application may not need rebuilding. In fact, the library versioning used by FreeBSD is designed with such application upgrades in mind. There's a problem because the pkg database gets screwed up if you delete the old package and install the new one. portupgrade deals with that for you. > Using pkg_tree, I've found that my current system is "a real mess". I've > not been using FreeBSD that long, since 3.4-RELEASE, and even in that time > I've seen several problems of this type. I've been admin'ing FreeBSD since 3.0-RELEASE (since the day of the release, as a matter of fact), and was using it before that. I've seen this problem exactly once - but I also have a good idea of when it's safe to ignore dependency warnings. If you think you shouldn't be allowed to ignore such dependencies, StpotUP. > I'm not sure whether I should take this to mean that I shouldn't follow > -STABLE, or quite what, but it does concern me that other packages I > have installed may be in the same situation. If they are libraries and > only minor version is different then the may be no problem. FreeBSD library versioning is specified that minor version numbers increasing indicate backwards compatability; major version numbers changing indicate that applications can't depend on the old behavior. http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message