Laszlo (Laca) Peter writes: > On Fri, 2007-01-05 at 13:43 -0500, James Carlson wrote: > > > > One feature that's missing, and would be infinitely useful for > > > online package repositories, is >= style version checking in > > > dependencies. E.g. if I have an xchat package that was compiled > > > against GNOME 2.16, I'd like to say in the depend file that it > > > needs SUNWgnome-base-libs >= 2.16.0. > > > > It's not missing from the underlying packaging standards -- see > > pkginfo(4) and depend(4). > > I know you can specify a list of versions for each dependency, but > you can do anything more flexible. I've just tried and even the > REV must match otherwise pkgadd complains. This make this feature > completely unusable. (Unless I missed something in the man page).
Yes; it's essentially an exact match. > > - Incompatible and disruptive change occurs only in particular kinds > > of (relatively infrequent) releases. > > These rules work great for an integrated product like Solaris. > But if I want to provide Solaris-compatible packages for download, > how do I verify that the dependencies are the correct versions? Build on the oldest version you want to support, because we intentionally support backward compatibility. > For example, if I offer a binary package of XChat for download, > and it was built against snv_53's GNOME 2.16, it'll work fine on > 2.16 and later but unlikely to work on snv_52, which had GNOME 2.14. > Compatibility is not working in that direction. It turns out that snv_52 and snv_53 aren't themselves releases so the issue is moot. But perhaps that point doesn't matter here. The existing rule is that you need to build on a system that is at least as old as what you plan to support. You can then test for that minimum system version and (because libraries are carefully designed to be stable ;-}) run on any newer version. > I'd like to say something like > > P SUNWgnome-base-libs > (i386) >= 2.16.0 > I SUNWgnome-base-libs > (i386) >= 3 > > i.e. my package will work with GNOME 2 version 2.16 or later but > won't work with GNOME 3, because that's a major version change. The original point above was about avoiding microscopic versioning because it tends to be difficult to maintain over time. I understand the request, and it's not an unfamiliar one, but it's just plain different from the direction Solaris had been going. To do something like that, someone's going to have to work out just how complex these entanglements can be and what the (new) software delivery rules are. It's not intuitively obvious, at least to me. I'd very much like to see Solaris avoid the mutually-exclusive dependency horror show I saw with apt on Debian ... shortly before I switched away. I realize the existing system doesn't support what *everyone* wants to do, but in adding new features, we do have to be careful to avoid wrecking existing simplicity. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
