This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ITP: netpbm


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]