This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: ITP: netpbm
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Charles Wilson <cwilson at ece dot gatech dot edu>
- Cc: Jan Nieuwenhuizen <janneke at gnu dot org>, cygwin-apps at cygwin dot com
- Date: Fri, 26 Apr 2002 14:22:52 -0400
- Subject: Re: ITP: netpbm
- References: <87r8l2pf8w.fsf@peder.flower> <3CC998A6.3030104@ece.gatech.edu>
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...)