pkg/10630: fvwm95 build stops at patch
Greg A. Woods
> Subject: Re: pkg/10630: fvwm95 build stops at patch
>
> The real problem is that the fvwm95 package is a _mess_. Both patch-aa and
> patch-ah modify the same file (modules/FvwmAudio/Makefile.in), and in fact
> the same line, the line which patch-ah changes, is first changed into the
> form in question by patch-aa!! (See below, the LIBS line...)
>
> (At some point before patch-ah was added, I had locally regenerated patch-aa
> with the same changes that patch-ah applied, and I haven't compiled it since
> patch-ah was added... That's what caused this specific build failure.)
Yet another reason why package patches should always be automatically
generated and kept in *ONE* file. :-)
This would definitely make it much harder for pkgsrc maintiners to make
mistakes like this.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
David Maxwell
> Yet another reason why package patches should always be automatically
> generated and kept in *ONE* file. :-)
>
> This would definitely make it much harder for pkgsrc maintiners to make
> mistakes like this.
Not really, it's just as easy to miss a file being modified in a patch
file when you're appending a new patch at the bottom, as it is to miss
it in a different file.
Now that there's a good tool for building patch sets though, getting into
a habit of using it to generate the whole patch directory would be good.
--
David Maxwell, da...@vex.net|da...@maxwell.net -->
Any sufficiently advanced Common Sense will seem like magic...
- me
Greg A. Woods
> Subject: Re: pkg/10630: fvwm95 build stops at patch
>
> > Yet another reason why package patches should always be automatically
> > generated and kept in *ONE* file. :-)
> >
> > This would definitely make it much harder for pkgsrc maintiners to make
> > mistakes like this.
>
> Not really, it's just as easy to miss a file being modified in a patch
> file when you're appending a new patch at the bottom, as it is to miss
> it in a different file.
Ah, but you should always rebuild the entire patch file, every time,
from scratch. If you have one patch file containing all "pkgsrc"
patches for a package then you never manually or otherwise edit that
file -- you only ever re-create it from scratch every time. This is
done either with a Makefile target like the "makepatches" target I
posted earlier, or with CVS (eg, with "cvs patch") if you use CVS to
assist in this job.
> Now that there's a good tool for building patch sets though, getting into
> a habit of using it to generate the whole patch directory would be good.
I find it hard not to use a tool that does all the work for me!
Of course anyone can argue that with a tool it's irrelevant whether or
not one builds one patch file or many patch files. However such a
narrow view of the problem ignores all the other negative issues
surrounding the use of multiple patch files.
Also note that regardless of whether there's one patch file or many,
there still needs to be some mechanism that identifies which changes go
into the official patches, and which are maintained separately (the so
called "PATCHFILES" patches, such as are in www/squid). With CVS this
kind of separation can be done with branches and merging. With more
"manual" techniques this can be done by automatically reversing the
third-party patches before trying to re-create the official patches. My
overly simple "makepatches" target doesn't deal with this issue (yet).