From owner-freebsd-libh Tue Oct 22 11:53: 6 2002 Delivered-To: freebsd-libh@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A52037B401; Tue, 22 Oct 2002 11:53:04 -0700 (PDT) Received: from mail2.qc.uunet.ca (mail2.qc.uunet.ca [198.168.54.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AADC43E77; Tue, 22 Oct 2002 11:53:03 -0700 (PDT) (envelope-from anarcat@espresso-com.com) Received: from xtanbul.espresso-com.com ([216.94.147.57]) by mail2.qc.uunet.ca (8.9.3/8.9.3) with ESMTP id OAA24234; Tue, 22 Oct 2002 14:52:49 -0400 Received: from anarcat by xtanbul.espresso-com.com with local (Exim 3.36 #1 (Debian)) id 184494-0000wS-00; Tue, 22 Oct 2002 14:52:50 -0400 Date: Tue, 22 Oct 2002 14:52:50 -0400 From: The Anarcat To: "James E. Flemer" Cc: freebsd-libh@freebsd.org Subject: Re: updating shared libs Message-ID: <20021022185249.GD3492@xtanbul.espresso-com.com> Reply-To: freebsd-libh@freebsd.org Mail-Followup-To: The Anarcat , "James E. Flemer" , freebsd-libh@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I don't think this belongs to binup to decide. As Mark mentionned in a previous mail, binup shouldn't deal with packaging issues itself. So I'm CC'ing this to libh, and setting reply-to. See me comments inline. On Tue Oct 22, 2002 at 02:07:27PM -0400, James E. Flemer wrote: > Wow, there is traffic here once again. Anyway, I was > wondering if anyone has ideas about how one would go about > replacing shared libs (assuming they are in use by running > procs). Will doing so cause any problems? I assume that > renaming a file won't cause problems because the inode is > preserved, so the VM will still know where the backing > store is. I'll answer by explaining a bit how portupgrade works. portupgrade, when hitting a shared libs it must upgrade, moves it to ${PREFIX}/lib/compat/pkg/, and the new shared lib is installed in ${PREFIX}/lib as usual. lib/compat/pkg is kept in the ldconfig path, so the old library gets picked up when needed by old packages. portupgrade suggest cleaning up the compat directory every once in a while, but I have found it near to impossible without recompiling a lot of dependent packages. Apart from that, you're right about the renaming. I think that you could even *remove* a shared library altogether and *running* process wouldn't be affected, because the libaray is already open(2)'d. Of course, new processes wouldn't start because they wouldn't link properly. > But what about upgrading something like libjpeg that may be in use > by lots of programs. How should a binup type program deal with this? I'll tell you how I think libh will work this out. libh packages will have 3 dependency specs: RequiredFeature: - min version - prefered version - max version If (say) ImageMagick requires libjpeg-2 and only libjpeg-1 is installed, libh will perform an upgrade of libjpeg-1 to libjpeg-2, if possible. And this is pretty important. This means that all packages depending having libjpeg-1 as "max version" will have to be upgraded too so that they link properly. LibH should take care of this automatically. Of course, if the upgraded dependent packages aren't available anywhere, they will have to be compiled from scratch or the upgrade will simply fail. I guess it would be possible to hack this to *force* libh to install the new libjpeg over the old one, but that's really against libh's spirit. > It would be nice if whatever binup process could provide > patch, rollback, commit type operations to test patches w/o > committing them on a running system. This would need a safe > way of messing w/ shared libs w/o breaking stuff though. libh is designed to have full rollback support. However this is not completely implemented. A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message