Re: ITP: plotutils-2.4.2 (trial Packaging too)

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

James R. Phillips wrote:

> The plotutils source package builds three cygwin packages:
>  2) plotutils-doc - extra documentation for plotutils

okay...

>  3) libplot       - link libraries and headers for using libplot

  This should be libplot-devel or plotutils-devel.

>  1) plotutils     - executable plot utilities and dll's

Do you expect any other package to use the runtime libraries?  If so, 
then they should be removed from the 'plotutils' package and given their 
own package -- preferably numbered, and preferably one package for each 
DLL.  Why?  Simple:

package 'foo' relies on cygplot-2.dll.
package 'bar' relies on cygplotter-2.dll.

And then you release plotutils-2.4.3 which has an interface change, and 
therefore provides not cygplot-2.dll but cygplot-3.dll.

now foo is broken.  Q.E.D.

Now, why should the various DLLs have their own packages, rather than 
all together in 'libplot2'?  Here's one reason: suppose there are NO 
interface changes in plotutils, but you release a new version using 
g++-4.0 (which may or may not use a different ABI than g++-3.4.4).  Now, 
the new C++ DLL, cygplotter-3.dll is not ABI compatible with 
cygplotter-2.dll, but as there were no actual interface changes, the C 
DLL is perfectly compatible and remains 'cygplot-2.dll'.  foo is happy 
-- but bar is broken:

'bar' used cygplotter-2.dll and can't use cygplotter-3.dll -- even if 
you didn't bump the DLLNUM and named it -2.dll you'd get a runtime 
failure because of the g++4.0 ABI mismatch.

(Now, I'm not saying that g++-4.0 is or will be ABI incomp; I'm just 
demonstrating that external factors can cause issues, which is why 
multiple DLLs from a single source package should each get their own 
"binary" package.)

--
Chuck