James Carlson wrote: > Laszlo (Laca) Peter writes: >> On Mon, 2007-01-08 at 13:57 -0500, James Carlson wrote: >>> 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. >> Exactly. But how do I express this as a package dependency? >> In other words, what stops users from installing my package >> on a system that is older than the oldest I plan to support? > > If you avoid microscopic package versioning, you either tell customers > "supported on Solaris X and above" and be done with it, or (if you're > feeling pedantic) you test uname -r and the existence of the objects > (such as /usr/lib/libfoo.so.1) in question during a preinstall script. >
Actually, that should be in a checkinstall script. > For things on existing versions of Solaris, delivery of patches gives > you a richer way to express dependency, because of just this problem. > It's not well connected with packaging, though. > Overall, though, I don't think integrating generic >= pseudo-numeric version checks in the packaging system is all that attractive; few of the versioning systems used by the different families of packages seem to behave consistently, either within themselves or across families, thus it seems a waste to invest there when it's only effective if discipline is observed by the package maintainers. Dave
