From owner-freebsd-questions Tue Nov 27 0:27:55 2001 Delivered-To: freebsd-questions@freebsd.org Received: from 217-126-145-95.uc.nombres.ttd.es (217-126-145-95.uc.nombres.ttd.es [217.126.145.95]) by hub.freebsd.org (Postfix) with ESMTP id ED58137B505 for ; Tue, 27 Nov 2001 00:27:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phoenix.ea4els.ampr.org (Postfix) with ESMTP id EBB343D43 for ; Tue, 27 Nov 2001 09:27:44 +0100 (CET) Date: Tue, 27 Nov 2001 09:27:44 +0100 (CET) From: Simon J Mudd To: Subject: Re: gv port builds but fails - needing libpng.so.4 (?) In-Reply-To: <15363.14157.861168.682892@guru.mired.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Tue, 27 Nov 2001, Mike Meyer wrote: > > > There's no reason to upgrade everything it depends > > > on in that case. > > 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). > > Ok, FreeBSD does A, assuming the packages database is up to date. What > happens for B is that it installs the old version as well as the new > one. In some cases, this works. In the cases where it doesn't, the > only harm done is that you'll have to reinstall the newer B a second > time. Getting warnings would give you the option of not upgrading A > until you had time to deal with all hell breaking loose. > > This can't be fixed as a general problem because applications - and > hence packages - change names. I.e. - cdrecord has become cdrtools. If > I have cdrecord installed, and install something that wants part of > cdrtools that wasn't in cdrecord, there's currently no way to solve > the problem. There are ways: I think rpm uses an obsoletes tag which implies "during the upgrade" that some package (other than one of the same name with a lower version number) must be removed. Obviously in these cases you have to provide explicit information to the package tools. > > Thus deleting packages doesn't seem to be the problem it's more installing > > is "too easy". > > I *never* expected to hear that said about *anything* associated with > a Unix system. You appear to be misinterpreting my comments here. I love unix's flexibility. In an ideal world a packaging tool isn't important, but in a production machine which you unfortunately _have_ to control and maintain having a system which keeps an eye on what's installed helps a lot. However you need to trust the tool, and currently I don't trust "ports" or pkg_add sufficiently because it doesn't warn me enough. Perhaps I need to do: setenv PORTS_SIMON_WANTS_LOTS_OF_WARNINGS=true cd /usr/ports/.... make install I'll have to work on a patch and send it in... :-) 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