Date: Sun, 18 Jan 1998 14:37:01 -0800 (PST) From: asami@cs.berkeley.edu (Satoshi Asami) To: ache@nagual.pp.ru Cc: peter@netplex.com.au, perhaps@yes.no, gpalmer@FreeBSD.ORG, ports@FreeBSD.ORG, committers@FreeBSD.ORG Subject: Re: amanda port, empty PATCH_STRIP= lines causes trouble Message-ID: <199801182237.OAA07740@baloon.mimi.com> In-Reply-To: <Pine.BSF.3.96.980119004158.14155A-100000@lsd.relcom.eu.net> (message from =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= on Mon, 19 Jan 1998 00:54:49 %2B0300 (MSK))
next in thread | previous in thread | raw e-mail | index | archive | help
* It seems that you mix several problems in one. I repeat (already many * times) that both new and old patch handle Index: equally. It was bug in * CVS diff affects _both_ new and old patch which was masked by "fixing" old * patch localy in FreeBSD which cause bugs with world-wide patches. Now old * patch is "unfixed" back and CVS is fixed instead. It means that old and * new patch handle Indexes equally (repeat one more). I wonder if anybody * really read what I write? Sorry, I did read that part but didn't understand what you meant. If that is the case, that change should be backed out too, at least until there is a release with a new cvs comes out. Or we are going to have a hard time working with user-submitted diffs (you know how the ports team get most of the stuff?). * It seems any junk can be written in the middle * of the message without a notice. There was different problems in new patch * related to no backups and -p strip slashes vs. path componetns, both * documented in patch(1). You keep saying it, but whether it is documented in patch(1) or not is irrelevant. Incompatibilities are incompatibilities whether they are written down or not. You can't replace a I586 with a MC68040 and keep the users happy because the manual now lists all the new opcodes. :> * _Before_ importing of new patch I ask everybody * about this problems and nobody seems to react which confirm that nobody * read what I write. I don't plan to waste time for importing and then * backing out. You should answer something before I plan to import. Sorry I didn't respond to it, but I was very busy last week because I was preparing for a talk. There were too many messages between you and Jeorg arguing about what's right and what's wrong I kinda skimmed over it after awhile, and wasn't aware you were planning to import a new version of "patch". * More * practical reason is that -current is place for new soft integrating and * patch integration is neccessary part so must happen sonner or later (I * already write that and repeat now to increase probability that someone * will read). I disagree. We should treat patch like gcc. Just because there is a new version doesn't mean we should jump on it on first sight. For a key system component like this, especially which has known incompatibilities with the old one, the way to go is port -> test -> import after consensus. Judging from the mails that are flying by lately, the new patch seems extremely unpopular in the way they "broke" ways people were used to work with diff/patch. (Who knows, the patch maintainers may even revert it back to the original method before long.) * Your bsd.port.mk system is not _golden_code_ remains untouched * by any price, so you must think how to adopt and handle new changes, it is * your task, not mine. If you think I'm doing this because of bsd.port.mk, you have completely missed my point (and others). It is about compatibility with all the patches out there (and more that are generated every day by 2.2.5R). bsd.port.mk is just a manifest of the symptom, not the problem. It is trivial to me to "hack" bsd.port.mk to work around the -b problem so the same file can be shared between old and new -current and any -stable. (I've done things like that in the past many times.) But that doesn't solve the bigger problem, and that's what we are saying. Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801182237.OAA07740>