Yury Tarasievich <[EMAIL PROTECTED]>: > ...then, Tim Kientzle wrote: > >> A better approach might be to simply fob it >> off on the user, i.e., >> >> # pkg_install foo-1.5 >> Warning: foo-1.5 requires bar-2.3, you have bar-1.7 installed. >> Proceed? [Y/n]
i think this is the best approach. > In my opinion, user should be bothered with choices *only* when, like > in this example, when dependency isn't *at* *all* satisfied. User > definitely should *not* be bothered when differences are irrelevant to > the functionality. E.g., ask only when bar-1.7 is installed and 2.3+ > required, not when bar-1.7 is installed and say 1.4.1+ is required. but i've seen libraries/interfaces changed dramatically. i faintly remember a package which would not link to Qt-2, but insisted on Qt-1 beeing used. > I think dependencies could / should also have *upper* revision limit > (library interface change, e.g.). And there could also be > functionality of system-wide dependencies updating (isn't there one?) but you cannot possibly know at what version number in the future some API will change. anything like this could only make sense if an API is described in terms of functionality needed, at a much finer grained level than version numbers. > I've seen interesting concept of version number processing by > D.J.Bernstein (called slashpackage, I believe). slashpackage doesn't really solve this problem, it is just a more rigorous framework. but since many of DJBs followers make programs as small as possible, with functionality spread over several programs where others make one big program, the granularity is in fact smaller. Title: slashpackage.html URL: http://cr.yp.to/slashpackage.html Last Modified: Mon Jul 16 00:24:39 2001 Title: Google Search: link:http://cr.yp.to/slashpackage.html URL: http://www.google.com/search?q=link:http://cr.yp.to/slashpackage.html especially: Title: idtools URL: http://multivac.cwru.edu/idtools/ Last Modified: Mon Jan 13 23:03:02 2003 (there's another packaging system for /package which i can't remember the name of, unfortunately.) the Installation of every package in /package is always the same: Create /package if necessary, unpack the tarball there, and run package/build: # mkdir -p /usr/local/package # Any filesystem will do... # ln -s /usr/local/package / # as long as it's visible as /package # chmod 01755 /package/. # cd /package # bunzip2 < /path/to/admin_idtools-VERSION.tar.bz2 | tar -xpf - # cd admin/idtools-VERSION # package/build # sp-version /package/admin idtools VERSION # sp-links /package/admin/idtools/command /command /usr/local/bin Read package/README and package/INSTALL for more detailed instructions. the last two commands are missing in packages not relying on paul jarcs idtools, and most packages provide a comprehensive script called ./package/install containing the building and installation. so far i have installed dozens of packages from different authors for quite diverse purposes, and the mechanism rarely failed, and if it did, it was for reasons like a forgotten include or somesuch. note that none of the packages use autoconf, AFAIR. clemens To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
