From owner-freebsd-ports Tue Nov 4 01:08:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA26432 for ports-outgoing; Tue, 4 Nov 1997 01:08:09 -0800 (PST) (envelope-from owner-freebsd-ports) Received: from messiah.cableinet.net ([194.117.157.68]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA26417 for ; Tue, 4 Nov 1997 01:08:04 -0800 (PST) (envelope-from i.vaudrey@cableinet.co.uk) Received: (qmail 11478 invoked from network); 4 Nov 1997 10:10:55 -0000 Received: from lions.cableinet.net (193.38.113.5) by messiah with SMTP; 4 Nov 1997 10:10:55 -0000 Received: from nemkoltd.nildram.co.uk (usr39-cro.cableinet.co.uk [194.117.149.49]) by lions.cableinet.net (950413.SGI.8.6.12/951211.SGI) via SMTP id JAA27789; Tue, 4 Nov 1997 09:06:01 GMT Received: by nemkoltd.nildram.co.uk with Microsoft Mail id <01BCE901.22C66E00@nemkoltd.nildram.co.uk>; Tue, 4 Nov 1997 09:07:54 -0000 Message-ID: <01BCE901.22C66E00@nemkoltd.nildram.co.uk> From: Ian Vaudrey To: "'Jordan K. Hubbard'" Cc: "'ports@freebsd.org'" Subject: RE: Ranlib Date: Tue, 4 Nov 1997 08:59:06 -0000 Encoding: 54 TEXT Sender: owner-freebsd-ports@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 04 November 1997 01:42, Jordan K. Hubbard wrote: > > I can reproduce the problem with at least one existing port, libmalloc-1.18, > > I haven't tried any others but if I'm right about the cause it'll happen > > with any port that has an @exec ranlib line in the PLIST. > > I'll take a look at it. Like I said, @exec lines aren't even supposed > to be _run_ by pkg_delete so this would be a very peculiar situation > of so. Looks like I'm still not explaining myself properly. As Satoshi said (with fewer words but greater clarity): "@exec ranlib" is run by pkg_add, and that changes the md5 checksum, which causes pkg_delete to choke. > > BTW, the refusal of pkg_delete to delete changed files is something that > > must've seemed a real good idea at the time, but in practice is a pain in > > the rear. This is the second time it's bitten me, there should be a way to > > override it. > > I suppose I could put in an override flag or something, but this > feature was actually specifically requested by the user base - it > didn't use to be this way. :) I can see why it was requested, but in some cases it really is a pain. Please, please, please add an override flag. After all, I thought it was part of the Unix philosophy to allow me to shoot myself in the foot whenever I want :) > > P.S. So *does* the @exec ranlib line serve any purpose? You of all people > > will know. > > I'm not sure if this is still true with the GNU loader, but in the > past even copying a library would generate "symbol table out of date" > warnings if the internal symbol table had an older creation date than > the library itself. > > Jordan Extracted from the ranlib man page: The options are as follows: -t Set the modification time of the __.SYMDEF file. Some loaders (but not the FreeBSD one) compared this time with the modifica- tion time of the archive to verify that the table is up-to-date with respect to the archive. If the modification time has been changed without any change to the archive (for example, by a cp(1)), the -t option can be used to ``touch'' the modification time so that it appears that the table is up-to-date. This is also useful after using the -t option of make(1). So it looks like the @exec ranlib line should really be @exec ranlib -t, but for FreeBSD it is *not* really needed anyway? Is that correct? - Ian