Date: Mon, 26 Nov 2001 04:22:29 -0600 From: Mike Meyer <mwm@mired.org> To: Simon J Mudd <sjmudd@pobox.com> Cc: questions@freebsd.org Subject: Re: gv port builds but fails - needing libpng.so.4 (?) Message-ID: <15362.6117.389492.58321@guru.mired.org> In-Reply-To: <74296747@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
Simon J Mudd <sjmudd@pobox.com> 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. <mike -- Mike Meyer <mwm@mired.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15362.6117.389492.58321>