Date: Wed, 9 Oct 2002 23:54:24 -0400 From: "Danny J. Zerkel" <dzerkel@columbus.rr.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: "M. Warner Losh" <imp@bsdimp.com>, FreeBSD-current@FreeBSD.ORG Subject: Re: Do we still need portmap(8)? Message-ID: <200210092354.24718.dzerkel@columbus.rr.com> In-Reply-To: <3DA498EA.C7BF77A@mindspring.com> References: <3DA1F203.6CD50B5C@mindspring.com> <200210072127.58523.dzerkel@columbus.rr.com> <3DA498EA.C7BF77A@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 09 October 2002 17:00, Terry Lambert wrote: > "Danny J. Zerkel" wrote: > > And a list of files to delete would have saved many emails about the > > GCC being broken when the old headers just needed to be deleted. > > No, it wouldn't. > > The same people who failed to read the mailing list, and see the > first time the problem came up, and was solved, would fail to read > the file. The information was available after the first time the > problem was successfully and publically addressed. Sigh... there should be a file listing incompatible files that is part of the source tree. Every file in this list would be deleted as a pre-install step. Perl would not have been in this list because it was not incompatible. But the old C++ headers clearly were. There have no doubt been other instances of incompatible files in the installation or examples of files moving. It will happen to any software system and should be accounted for in the installation mechanism. > I challenge you to contact everyone who has posted complaining > about the "stale header file problem" in the last 6 months, and > ask them what resources they looked to for a solution, before > they contacted the mailing list. > > I will be incredibly surprised if you find that they have any > single "README" or other file in common, where such information > could have been placed. > > If you *do* find such a file, then you should create a patch, so > that there will be no more postings of the question by users as > they run into it. > > > The reasons volunteers automate processes are (1) "for their own > use", (2) "to advocate something", or (3) "to get other people to > shut up". > > The reasons the topic of automating this process keep coming up > are the same; I would say that 90% of the people involved in the > discussion (including myself) are in camp #3. > > Yes, it would be nice if this were automatic, but not if it screws > up the ability to run perl scripts (as one example). > > > If you want to address it systematically, then what you can do > *right now* is cause a file containing a build identifier to be > installed as part of the "install world" or "install from CDROM" > process that will allow the current system to be recreated. > > A delta management system is only as good as the timestamp from > which the deltas are managed, relative to the current timestamp. > > Personally, I suggest a file "/etc/BUILD" be created to contain > the CVS tag and a timestamp indicating the checkout time, created > as part of the build process (maybe the tag from the output of a > "CVS stat" on the Makefile in /usr/src, processed to deal with > sticky tags, and the date stamp on the file itself, otherwise). > Yuck. Let's NOT not use CVS (Cantakerous Version Scrambler) tags. > Everything else can be hung off that. > > -- Terry Danny dzerkel@columbus.rr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210092354.24718.dzerkel>