...first, clemens fischer wrote:
Yury Tarasievich <[EMAIL PROTECTED]>:I'd like to see in dependencies not only like "was built with
-1.9_2abc, so wants it", but also something like -1.5+ (obviously
1.5.0 and newer), -* (any version will do). Perhaps something else. At
least to have possibility of specifying that, if this can't go into
official ports. Does it seem reasonable?
this problem has been annoying me for ages, but he who implements this should consider dependencies specified too liberally. sometimes newer versions aren't backwards compatible, which you can't know back in the past.
Well, someone *should* pay *some* attention to what he's porting, right? And I've seen some ports even aren't compliant with hier(7), too. ...then, Tim Kientzle wrote:
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.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 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?)
I've seen interesting concept of version number processing by D.J.Bernstein (called slashpackage, I believe).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
