From owner-freebsd-current Thu Apr 8 16:51:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (Postfix) with ESMTP id 43F0314DB2 for ; Thu, 8 Apr 1999 16:51:28 -0700 (PDT) (envelope-from jfieber@fallout.campusview.indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.9.2/8.9.1) with ESMTP id SAA31014; Thu, 8 Apr 1999 18:49:13 -0500 (EST) Date: Thu, 8 Apr 1999 18:49:13 -0500 (EST) From: John Fieber To: Peter Jeremy Cc: bartol@salk.edu, current@FreeBSD.ORG Subject: Re: /sys/boot, egcs vs. gcc, -Os In-Reply-To: <99Apr9.085646est.40354@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Apr 1999, Peter Jeremy wrote: > There's no mechanism for updating a package - and it's not clear (to > me anyway) how this can be done safely in a general way. Where the > update is only minor (and won't affect the dependent packages), you > can use something like: For an update to work, files that must be preserved (shared libraries mainly) over an update must be tagged. If libfoo-1.0 is installed and I upgrade to libfoo-2.3, the libfoo-1.0 package should be removed except /usr/local/share/libfoo.so.1.0. Then libfoo-2.3 gets installed and *inherits* /usr/local/share/libfoo.so.1.0 in its +CONTENTS so that if you want to do a wholesale removal of the libfoo package in the future, you can do it. A completely different approach to this dependency nightmare is to link statically. I know there are drawbacks to this and the costs are too great in numerous situations. But if you *can* practically do this, you can demote a runtime dependency to a build time dependency which is a Good Thing for your sanity. -john To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message