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

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

James R. Phillips wrote:

> Your example [not quoted] is a good one, because the libraries are libplot and
> libplotter, of which libplot is C, and libplotter is C++.  I guess libxmi is in
> there too - I think that is C.
>
> Can you suggest an appropriate naming/numbering scheme?  Would I just append
> something to the plotutils version number, starting at 1 and incrementing as
> necessary?

Simple:
   cygplot-2.dll     ---> libplot2-2.4.1-X.tar.bz2
   cygplotter-2.dll  ---> libplotter2-2.4.1-X.tar.bz2
   cygxmi-0.dll      ---> libxmi0-2.4.1-X.tar.bz2

That is, the package name tracks the libtool DLLNUM appended to the DLL.

Now, the only time you should bump the DLLNUM (and thus, create a new 
packagename for that DLL) is when there is a backwards incompatible 
change to the API/ABI.  E.g. if an new function is added -- that is NOT 
a reason to bump the number.  If a function is removed or its signature 
is changed, OR there is an ABI change (g++ borkeness, etc), THEN you 
bump the DLLNUM, create a new package, etc.

If this ever happens, there are some other things you need to do so that 
the GPL is satisfied (e.g. the "obsolete" package's setup.hint needs to 
stop using 'external-source:', and should get its own copy of the -src 
package, etc).  See 
http://sources.redhat.com/ml/cygwin-apps/2005-07/msg00228.html for more 
info (and note that the package discussed there, readline, violates some 
of these guidelines! [*])

How to bump the DLLNUM?  Edit the Makefile.am file and modify the 
'-version-info c:r:a' flag: the DLLNUM == c - a.

> I will say one thing before we start on this: plotutils development is dead

That's too bad.  The changes I made are cross-platform and bring 
plotutils into the modern era of autotools...it's be nice if "someone" 
could authorize a micro-update incorporating them.  But you're right, I 
couldn't find an active mailinglist...

, so
> the only library changes are going to be from things like the C++ abi change
> you mentioned.

Yep.

--
Chuck



[*] cyghistory-N.dll and cygreadline-N.dll are both in the same package, 
because cygreadline actually includes all of the source used by the 
lightweight cyghistory.  Therefore, the DLLNUM will always be the same, 
so there's no need for two separate packages -- which is only necessary 
when the DLLNUM/packagename might diverge.

In plotutils' case, the source code in cygplotter == cygplot + cygxmi 
(so if cygxmi changes, then cygplotter changes but cygplot does not), 
plus there's the fact that two different languages are involved -- so we 
need to plan ahead for DLLNUM divergence.

With regards to the "main" package and the "devel" package being merged, 
I hope it's obvious that plotutils should not follow that example.