Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Jan 1998 15:54:45 +0300 (MSK)
From:      =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
To:        Satoshi Asami <asami@cs.berkeley.edu>
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:  <Pine.BSF.3.96.980120153843.24732A-100000@lsd.relcom.eu.net>
In-Reply-To: <199801201235.EAA18344@baloon.mimi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Jan 1998, Satoshi Asami wrote:

> (1) ncurses patch specifies the file's relative pathname in the Index:
>     line but "old" (2.2.5R) patch interprets them bogusly (whatever
>     that means) and tries to patch the wrong file
> 
> (2) ncurses patch has correct relative pathnames in ***/--- lines and
>     Index: lines that is not the relative pathname of the file in
>     question, so "old" patch tries to patch the file specified in
>     "Index:" and fails

Not first and not second :-)

Here is typical header from ncurses patch:

Index: src/Makefile
*** 1997NNN/src/Makefile
*** 1997XXX/src/Makefile

Automatic system calls 'patch -p1'

In standard GNU patch (any version) 1997NNN is stripped producing
src/Makefile, in "fixed" FreeBSD patch src is stripped producing Makefile,
and most unpleasant thing is that Makefile exist too and is very similar
with src/Makefile, i.e. Makefile was successfully patched instead of
src/Makefile!

> Can you make a filter like that work reliably?  And are we going to
> call it "patch"?

I already think about alternate /usr/bin/broken_patch especially for
ports system, but even in this case it should be NOT be called for 3-rd
party "distributed" patches, standard /usr/bin/patch should be called
in such cases.

> 
>  * I start to fear where FreeBSD project goes. The thigs like 1) easily
>  * sneaking hacks (causing essential bug) together with 2) unwiling to remove
>  * them argumenting with functionality reasons are clear signs of
>  * degradation. I ever not mention that nobody seems to read even the first
>  * line of my message.
> 
> I'm starting to fear too.  I really don't like the current atmosphere
> in which it seems people who yell louder always get their way because
> others just get too annoyed to argue. :<

It not helps to yell loud if nobody listen, trust me.
It seems I have bad Karma to explain in details what happens with patch to
each and every core team member separately, because others not read
this discussion until something not works as expected for them.

Anybody can argue in the case when it is unclear is it a bug or not,
but when it is definitely a bug, there is no arguments possible by
the definition of bug word.

"because it breaks" is not an argument, some another ways must be found to
compensate what is broken, not backing out bugfix. 

-- 
Andrey A. Chernov
<ache@nietzsche.net>
http://www.nagual.pp.ru/~ache/




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980120153843.24732A-100000>