Mail Archives: cygwin-apps/2002/04/27/13:39:15
Jan Nieuwenhuizen wrote:
>>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...
>>
>
> Ok, I'd like to have a look. What do these patches do, ie, (why)
> can't they flow upstream?
Well, as I described in the other message, there are only three patches.
One, which creates a Makefile.config, so you don't have to run netpbm's
configure (which is NOT autoconf-generated, and requires manual
intervention when you run it). That is, netpbm WITHOUT a prebuilt
Makefile.config can't be built via an unattended script.
Two, a cygwin-specific README file.
Three, GNU shtool, to create a shadow tree in which to build. Without
this, it's hard to automatically generate a patchset using an unattended
build script.
These changes are all specific to the script-based unattended build
setup used by cygwin packages (method 2:
http://www.cygwin.com/setup.html). They aren't appropriate for
submission upstream.
What *would* be appropriate is if someone totally autoconfiscated the
whole mess, so that you could do a GNU-standard, unattended ./configure
--my-favorite-options. Then you wouldn't need GNU shtool, or the
prebuild Makefile.config.
>>Also, which png have you linked against? 1.0.12, or 1.0.13?
>>
>
> 1.0.13.
>
> I'll change dependencies to libpng10, and will split the package into
> netpbm, libnetpbm9, libnetpbm9-dev[el], simply mimicking what Debian
> is doing; that should be enough?
Probably...now that I've looked closer, it seems that all four p*m
libraries use "9" as their MAJor version and so-number, but they have
different MINor revision numbers. Assuming that the so-number will
change only when backwards incompatible changes are made, then we could
probably assume that the putting all of the shared libs into
"libnetpbm9" would be okay.
However, currently the DLLs are named "cygp?m.dll" without a
distinguising DLL/so number. I'll look into fixing that -- which IS an
upstream-submittable patch...
> I'll have to read up to the # binaries thing, the only thing I would
> like to consider* is moving /usr/bin to /usr/bin/netpbm, but I'd
> rather not.
> * but only if there's a good reason because of broken filesystem and
> lookup support, and some sort of consensus (summary, anyone? :-)
Big directories == slow. Much worse on FAT than on NTFS. There's no
hard limit on non-partition-root directories, however (unless somebody
does something REALLY silly, like 'mount C:\ /bin'.
Putting all the netpbm binaries in /usr/bin(==/bin) won't cause any
problems, except for the standard PATH ordering issues(*), but those
will only affect a few people (like me, and I can deal).
--Chuck
(*) there are widely used windows ports of netpbm tools. MikTeX even
distributes one. I like to put cygwin's bin/ at the front of my PATH,
but bin/netpbm is NOT in my windows path. When I start a bash shell, my
.profile moves bin/netpbm toware the front of my PATH.
So, in normal windows, and cmd prompt, I use the native port of netpbm
(this makes miktex and friends happy; also I have direct access to the
OTHER cygwin tools since cygwin/bin is at the front (and the
cygwin-netpbm tools aren't in there). When in bash, I use the cygwin
port of netpbm (this makes me happy). But it's tricky, and not possible
unless the cygwin netpbm tools are segregated from the other cygwin
binaries.
However, this is a rare situation, and anybody who knows enough to want
to do it, knows enough to implement it regardless of how you package
cygwin-netpbm.
- Raw text -