Date: Fri, 03 Nov 2000 13:00:03 -0800 From: Tim Kientzle <kientzle@acm.org> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: libh@FreeBSD.ORG Subject: Re: Making the Packages System Better Message-ID: <3A032753.E596C98D@acm.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
"Daniel C. Sobral" wrote: > Actually, I have little experience with Solaris. :-) Lucky you. ;-( > "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. > Upgrades you solve by keeping a list of what files need to be taken > special attention of, scripts to handle them if necessary, and just > paying attention to what IS in the database before installing. The problem isn't just upgrades, but repeated upgrades/downgrades. The scheme I propose would allow the pkg_* tools to deal with that cleanly in most cases. (For example, I recently had five different versions of java installed on my system and had to switch between them a number of times to find the one whose bugs and/or deficiencies least affected my work. The current FreeBSD packages generally don't handle this situation gracefully. I had to deal with this manually--with some assistance from the ports collection---and I would rather not have to.) > > ... 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. > > At the very least, the default PREFIX should be changed to something > > other than /usr/local. That would reduce the brittleness of the > > current system. It wouldn't address many other issues, of course. > > 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 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. 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.) - Tim Kientzle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A032753.E596C98D>