[osol-discuss] Re: rpm vs pkgadd (again!)

[Peter C. Norton]

On Fri, Jan 05, 2007 at 02:34:27PM -0800, John Plocher wrote:
> UNIX admin wrote:
> >if I need REV 1.0 or 2007.01.05.07 of some dependency,
> >and I have REV 3.2 or 2007.04.18.23 of the said software,
> >`pkgadd` should be able to recognize that I have satisfied the min REV 
> >required, and plough on instead of doing a string-like check and 
> >*insisting* that I need *exactly* REV 1.0 (or 2007.01.05.07, for example).
> 
> The fallacy here is in *assuming* that rev 3.2 is exactly compatible
> with your 1.0 usage.  As Jim said, Sun's approach to this problem has
> been to "say what you mean, and mean what you say".  That is, be
> explicit about your promises (the interface taxonomy) and follow
> up on those expectations by being honest with your version numbers
> (the release taxonomy).
> 
> If the bits you are producing are compatible, we say that the major
> and minor version identifiers for your released component stay the
> same.  And, if you make an incompatible change, you also need to
> change the high order version number(s).

The linux packaging tools are way ahead in this respect.

1) Upon package creating, the tools automatically scan for known
   dependancy types. dynamic libaries are scanned for symbol names and
   versions (as supplied by the linker, I guess), perl, python and
   concievably other interpreters will be scanned for statements that
   indicate dependancy such as "use" in perl, or "import" in python.

2) In specifying the package, you can explicitly specify that a
   package is incompatible with any level of
   major.minor.subversion-release of any other package, and you can
   force lower versions of a package by using a special version
   information tag called an epoch that will supercede other version
   information.

3) You can state in the package metadata that it provides something
   such as another package, a specific library (in case it is
   non-obvious).

4) You can turn off dependancy checking on a per-file, per-library,
   etc. basis or provide your own because it's very possible that you
   know better than the packaging system.

5) Rpm is rpmbuild as well.  Though you don't have to use it to build
   the software and the package, it's a lot easier and usually a good
   discipline because it automates much of the process.

> This way, anything that depended on the 1.0 interfaces could safely
> depend on any "later" 1.0.* release of the library, but could not
> safely depend on a 2.* version because, by definition, the 2.0 version
> exhibits incompatibilities with the previous 1.0 stuff.

That's why rpmbuild usually goes for library version symbols -
libraries change a lot. However shell scripts, binaries, etc. usually
have more stable interfaces. However as those change, there are tags
to indicate that the package is incompatible with it's older version,
and taa-daa, it's now incompatible with packages that depend on the
older version.
 
> In this world view (which is by no means universal), it would be
> a bug to implement dependency equivalence as you suggest, because,
> as the quote goes, "it just ain't so!".

In practice the solaris shops I've worked at will simply ignore
dependancy information because it will prevent perfectly working
combinations of software that are intedned to work together.  With a
better packaging system and package creation standard, most things can
be accomodated easily.  I don't know why this state of affairs is
considered acceptable, let alone preferrable.

What am I missing?

-Peter

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.