Re: Making pkg_XXX tools smarter about file types...

[Yury Tarasievich]

clemens fischer wrote:

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.

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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message