Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com Message-ID: <3CCAE2DD.7030605@ece.gatech.edu> Date: Sat, 27 Apr 2002 13:41:49 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Jan Nieuwenhuizen CC: cygwin-apps AT cygwin DOT com Subject: Re: ITP: netpbm References: <87r8l2pf8w DOT fsf AT peder DOT flower> <3CC998A6 DOT 3030104 AT ece DOT gatech DOT edu> <87it6dpm70 DOT fsf AT peder DOT flower> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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.