Date: Tue, 11 Feb 2003 16:27:45 +0200 From: Yury Tarasievich <grog@grsu.by> To: freebsd-hackers@freebsd.org Subject: Re: Making pkg_XXX tools smarter about file types... Message-ID: <3E490861.70809@grsu.by> References: <3E42C148.4050807@acm.org> <3E440393.3080506@grsu.by> <smuxs891.fsf@ID-23066.news.dfncis.de> <3E47C1BA.9000500@grsu.by> <y94nm4ob.fsf@ID-23066.news.dfncis.de>
next in thread | previous in thread | raw e-mail | index | archive | help
clemens fischer wrote: >Yury Tarasievich <grog@grsu.by>: > >>...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. > > I still disagree with that partially (as in quote below). >>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. > > So have dependency list insist on having available qt-1<no-higher>. Not the most appropriate example, either (I would have thought of dividing line like "method changed behaviour over some revision number"). QT's have different naming schemes (IIRC) and different functionalities, effectively being 3 different packages. >>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 agree with that but then I don't see what is *the* problem? I believe it *is* known what functionality gets changed and how, when package goes through revision change? >>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 > > [...] No, I was thinking about that (citing cr.yp.to/slashpackages/versions.html): > Which version is newer? > > Version numbers are required to start with digits, but they aren't > required to follow any particular numbering system. In particular, > they aren't required to increase lexicographically. One package might > have versions 2, 2.01, ..., 2.09, 2.1, 2.11, ..., 2.89, 2.9, etc., > while another package has versions 2.0, 2.1, 2.2, ..., 2.9, 2.10, > 2.11, etc.; 2.11 may be before or after 2.9. > > If you're building a package, you can include a file > ./package/versions that lists all the version numbers you've used so > far, one per line, in order. Then scripts can compare two versions to > see which one is newer. For example, if > /package/admin/daemontools-0.80/ package/versions says > > > 0.75 > 0.76 > 0.80 > > > while /package/admin/dameontools-0.92/package/versions says > > > 0.75 > 0.76 > 0.80 > 0.81 > 0.90 > 0.91 > 0.92 > > > then 0.92 is newer. This file also makes it possible to reliably > handle dependencies such as ``you must have version 0.81 or newer.'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E490861.70809>