From owner-freebsd-libh Fri Nov 3 19:57:57 2000 Delivered-To: freebsd-libh@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 59A3937B4D7 for ; Fri, 3 Nov 2000 19:57:54 -0800 (PST) Received: from newsguy.com (p03-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.132]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id MAA16510; Sat, 4 Nov 2000 12:56:39 +0900 (JST) Message-ID: <3A038899.681CB9DD@newsguy.com> Date: Sat, 04 Nov 2000 12:55:05 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: kientzle@acm.org Cc: libh@FreeBSD.ORG Subject: Re: Making the Packages System Better References: <39DCC860.B04F7D50@acm.org> <20001006155542.A29218@cichlids.cichlids.com> <39F3CDD7.15B889E7@acm.org> <20001023190412.B507@cichlids.cichlids.com> <39F47E98.4BB647AA@acm.org> <20001023202244.B10374@cichlids.cichlids.com> <39F48F4A.38D458C2@acm.org> <39FCF244.5A8C8E59@newsguy.com> <39FDC12E.304B0011@acm.org> <39FE2406.150CA3B1@newsguy.com> <00cb01c042f1$1a347190$040aa8c0@local.mindstep.com> <39FE562C.714DBE7C@newsguy.com> <39FFCD73.7364C2BF@acm.org> <39FFE5B7.8FC4216B@newsguy.com> <3A0063F5.4798055B@acm.org> <3A00CC6B.39522CF0@newsguy.com> <3A01BDA9.C637C0AA@acm.org> <3A02209D.5E7137F8@newsguy.com> <3A032753.E596C98D@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tim Kientzle wrote: > > > "Package installation," for me, is cd /usr/ports/Category/Application; > > make all install clean. Optimize for pkg_add is optimizing for the wrong > > target. > > The current ports are already optimized for pkg_add, and I have > yet to find anything in the existing ports system that would > require changing current ports to support the scheme I suggest. > If you don't use pre-compiled software packages, you will be > entirely unaffected by any change to how they work. I beg your pardon, but having pkg_info, installing things elsewhere, etc, *DO* change the way things work. Your changes are *not* related to pre-compiled packages! Whether you get your stuff from a .tgz (or whatever), or you get your stuff from a directory that just has been compiled is irrelevant wrt your changes. It's the *management* from there on that changes. > > > ... several decades of standard Unix practice ... > > > use /usr/local for local software. > > > > ... /usr/local has been used for DIFFERENT purposes by different > > vendor and people. :-) > > Exactly my point. And, in FreeBSD in particular, it has been used for ports since 1994. > > Huh? Why something other than /usr/local? > > Because, as you pointed out, "/usr/local has been used for DIFFERENT > purposes by different vendor and people". People have different > (strongly-held) opinions about the use of /usr/local; FreeBSD's Some do. In many systems /usr/local has never been used for anything. We have two main targets here. One, our userbase, which has been using /usr/local our way since they started using FreeBSD, for how long that may have been. Two, new users, who, by and large, have not been exposed to any Unix hierarchy, with the possibly exception of one of the many Linux distributions. The people who have been using /usr/local for something other than we do and have strongly-held opinions are in minority. In particular, they are most likely in minority compared to our user base. > package system should steer clear of such issues and leave /usr/local > alone for individual sysadmins to use as they see fit. If they > want to fix PREFIX to /usr/local, let them; but, if they'd rather > use it some other way, FreeBSD's packages should not dissuade that. That would have been an option six years ago. Now, it is not. > Also, something to remember: installation/upgrade/deinstallation > isn't just a question of what's in the database. It's more > importantly a question of what's in the filesystem. If those > two get out of sync for any reason, the filesystem should > be the definitive source, not the database. (I've heard > many complaints about RPM, for example, in part because > it doesn't consider the filesystem as a place where > dependencies might live. As a result, it will often > refuse to install something if the dependency wasn't > installed from an RPM.) That way lies autoconf, which I'm not even dignifying to comment on. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@world.wide.bsdconspiracy.net He has been convicted of criminal possession of a clue with intent to distribute. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message