--- Charles Wilson <[EMAIL PROTECTED]> wrote:
> 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 >
