This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: ITP: plotutils-2.4.2 (trial Packaging too)
- From: "James R. Phillips" <antiskid56-cygwin at yahoo dot com>
- To: cygwin-apps at cygwin dot com
- Date: Sun, 9 Oct 2005 21:00:46 -0700 (PDT)
- Subject: Re: ITP: plotutils-2.4.2 (trial Packaging too)
- Reply-to: antiskid56-cygwin at yahoo dot com
--- Charles Wilson <cygwin@cwilson.fastmail.fm> 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
>