David O'Brien wrote: > On Mon, Aug 09, 2004 at 11:19:29AM +0200, Oliver Eikemeier wrote: >> David O'Brien wrote: >> >>> On Tue, Aug 03, 2004 at 08:31:15PM +0200, Oliver Eikemeier wrote: >>>> As usual, file(1) has to follow. Anyway, since it works for now, and >>>> currently there is no reason to break it, why is it bad? I actually >>>> like >>>> that feature, and it is useful for debugging ports that should have >>>> been >>>> recompiled after a system upgrade. >>> >>> Sounds like you're trying to work around bugs in the Ports Collection, >>> please go fix those bugs and use the proper tool for the job. >> >> Could you please elaborate which bugs you are referring to? The current >> file(1) works fine for me in this aspect, so what are better tools for >> the job? > > It appears you're concerned when FreeBSD X.Y comes out, you've got ports > compiled on X.(Y-1). This is not a problem, and I'm not sure why you > feel it is that you appear to run file(1) across all of /usr/local and > /usr/X11R6 and reinstall any binaries you find from X.(Y-1). Since X.Y > will run X.(Y-1) binaries just fine I'm not sure why you have this need. > portupgrade(8) is the proper tool to refresh all your ports. If you > find > that X.Y can't run an X.(Y-1) binary then the root cause of that bug > should be fixed. You might notice that 5.3-RELEASE won't run all 5.2.1-RELEASE binaries. > I don't see that your method of running file(1) across everything scales > well to the typical user. The magic word here is `debugging' (see above). When you read src/UPDATING you might notice that some updates require recompilation of affected ports. It is very convenient to let users submitting bug reports run file(1) on the affected binary, and, given that it has been compiled on an older release, tell them that they missed the entry in UPDATING, which suggested to recompile the port. -OliverReceived on Mon Aug 09 2004 - 07:46:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:05 UTC