Mail Archives: cygwin-apps/2002/04/26/14:33:53
Oh, yeah, one other thing: runtime requirement is probably either
libpng2 or libpng10, not 'libpng'. Build requirement is either libpng
or libpng10-devel. (the first of each pair if 1.0.12, the second of
each pair if 1.0.13).
Okay, *two* more things: you may want to package this "the right way"
from the beginning -- and avoid the pain I (and everyone else by proxy)
went thru. Split out your DLLs from everything else and have two
packages...'netpbm' and 'libpnmXX'. That way, when user bob builds
gnuplot against your 'libpnm1' DLLs, his gnuplot will still work even
after he upgrades to your newer netpbm package and libpnm2 DLLs --
because libpnm2 will (a) contain DLLs with names that are different from
those in libpnm1, (b) can coexist on the same machine.
Naturally, you'd only bump the libpnmX package number (and DLL numbers)
when there was a backwards-incompatible change; ordinarily you'd just
release a new libpnm1 package and overwrite the old DLLs with
new-and-improved, but compatible, DLLs.
Now that I think about it, you might want to split ALL of the DLLs into
separate libpbmX, libpgmX, libppmX, libpamX packages -- IIRC the netpbm
maintainer(s) follow different sequences on backwards compatibility on
the libraries. There's no need to bump the "so" number and force new
downloads of cygpbmX.dll, cygpgmX.dll, and cygpamX.dll, if only
cygppmX.dll had a backwards-incompatible change...
--Chuck
Charles Wilson wrote:
> Wonderful, please do.
>
> BTW, I have had a private version of netpbm, packaged in a
> 'setup-compatible' way, for some time now. When I get home, I'll put my
> version somewhere that you can access; you may want to expropriate some
> of my patches...
>
> Also, which png have you linked against? 1.0.12, or 1.0.13? (Also, I
> have libpng-1.2.2 ready for upload to sourceware, but I'm waiting for
> the ripples from the massive 1.0.13 packaging changes to settle out...)
- Raw text -