Date: Mon, 26 Nov 2001 20:07:35 +0100 (CET) From: Simon J Mudd <sjmudd@pobox.com> To: <questions@freebsd.org> Subject: Re: gv port builds but fails - needing libpng.so.4 (?) Message-ID: <Pine.LNX.4.33.0111261946530.1524-100000@phoenix.ea4els.ampr.org>
next in thread | raw e-mail | index | archive | help
mwm@mired.org (Mike Meyer) writes: > 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. I don't (normally) use packages, using ports directly. AFAIKT ports and packages are "identical", except that with ports you build the package before installing it. The packages are pre-built "ports". Is this understanding wrong? > > - 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. If it's not required it shouldn't be a problem. If it _is_ required then maybe several other ports _should_ be rebuilt. > 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. I am aware of that. I've not been using UNIX for _that_ long and am sure you have more experience than me in this, but I personally like a package manager which doesn't easily let me mess up my installed ports/packages. My _feeling_ is that currently FreeBSD ports can let you do this. The fault may be mine, it may be the documentation, and that's really why I haved asked on -questions to try and determine what's going wrong. > > - 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. Understood. If the locations _are_ different then yes allow multiple installs. I agree. However, allowing you to install multiple ports with conflicting locations should at least provoke a warning, which can be overridden if the user knows what he is doing. > > - 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. The problem perhaps is that once you've isntalled two conflicting copies of a port it is impossible to uninstall one without affecting the other one. You also don't know which port is _really_ installed completely (if at all). So you can't go back from this situation, and it's easy to get into it. This may be a matter of putting newbie-wrappers around the existing tools, or having the man pages warn in the appropriate places. Current port documentation doesn't really cater for this. > > - 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. Fine. > There's no reason to upgrade everything it depends > on in that case. You'd only need to do that if you change the dependencies of the port you are upgrading: If you want to upgrade portA-1.2.3 -> portA-1.2.4 and both depend on portB, (no version specific information here), then there's no problem. This would be the normal situation. If you want to upgrade portA-1.2.3 -> portA-2.0.1 and the dependency for portA-2.0.1 is for a package portB-X and the installed version of portB is less than X, then this doesn requires portB to be upgraded. Obviously this is the situation where "all hell may break loose" because this may require further package upgrades. Ideally the packaging system would tell you two things: (A) you can't do this if other ports depend on the installed version of portB (B) if you do this you'll need to upgrade other ports which depend on portB to ensure that the system stays "stable". rpm does (A) which is obviously easier, and I'm not aware of a packaging system which does (B). > > 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 don't think the dependency warnings are the problem. You are right they are there. However a (ignorant?) sys admin who installs a newer version of a port/package without uninstalling the older one first can have problems. I guess this can also happen if the package depencies change and a newer version of a package is required: the ports will install the package over the top of the currently installed version (without warning). Thus deleting packages doesn't seem to be the problem it's more installing is "too easy". > > 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. I think this is true of other versions of unix too. I am aware however of the effort made to ensure that upgrade compatibility means that normally you shouldn't have trouble cvsuping to the next -release, and that's very good. I hope you don't think I've been picking on you. I appreciate your time, even if I've laboured the points with you somewhat. I don't know anyone personally who is sufficiently knowledgable about FreeBSD to "teach me way". Simon -- Simon J Mudd, Tel: +34-91-408 4878, Mobile: +34-605-085 219 Madrid, Spain. email: sjmudd@pobox.com, Postfix RPM Packager 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?Pine.LNX.4.33.0111261946530.1524-100000>