[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: patches question

From: Andreas Enge
Subject: Re: patches question
Date: Thu, 23 Jun 2016 22:27:53 +0200
User-agent: Mutt/1.6.1 (2016-04-27)

On Thu, Jun 23, 2016 at 01:23:47PM +0000, ng0 wrote:
> Firefox wip, untested, not even run, just filling in fixes
> which very likely have broken syntax looks like the later
> inserted file. In this file there is a 140+ lines phase
> which aims at doing what the following inserted patch
> does. It is still growing (2 files left to patch).
> As 'maybe' icecat can make use of the harfbuzz graphite
> phase in this case it makes more sense to drop it
> into gnu/packages/patches/ .. right?

I must admit I have difficulties understanding what you are trying to do
(after I finally managed to parse the first sentence above, in which it
is rather unclear who or what is the subject of the different verbs).
It is clear that the complicated scheme "substitute*" in your package
definition are inferior to a real patch; if all they do is just reimplement
finely chiselled patches, they do not make sense.

The example I had in mind for uses of "substitute*" was when a string could
be replaced by another one everywhere in files, for instance "/bin/sh" by
"sh" or these kinds of things; then "substitute*" will still work, even
if a few lines are swapped in the file or the string occurs once more or
less in a later version. A patch would fail in that situation.

It looks like you are trying to use the system harfbuzz instead of a bundled
copy? Or the system graphite? If that is the case, maybe it would be optimal
to propose a patch upstream? The icecat package definition contains a few
comments pointing to bug reports at


reply via email to

[Prev in Thread] Current Thread [Next in Thread]