[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnu: shepherd: patch, snippet or phase
Re: gnu: shepherd: patch, snippet or phase
Sun, 01 May 2022 14:34:12 +0800
mu4e 1.6.10; emacs 27.2
IMO, It's cumbersome to add patches in build phase, you have to add a
new phase, and write something like:
(invoke "patch" "-p1" ...)
So packager will prefer to add it in the `patches` slot of <origin>
struct. I'd like to see if we have some build procedure like
`apply-patches` to help packager reduce the misnomer of `patches` slot.
Or we can add a new keyword argument #:patches-for-build to
gnu-build-system. For example
(patches (search-patches "...."))))
;; This patch only used when building the package
#:patches-for-build (search-patches ".....")
zimoun <firstname.lastname@example.org> writes:
> Hi Maxime,
> On Sat, 05 Mar 2022 at 22:49, Maxime Devos <email@example.com> wrote:
>> (as implied per zimoun's previous mail (‘FWIW, it would be unfair for
>> the patch to have the discussion here’), moved to guix-devel)
> Thanks. :-)
>> Leo Famulari schreef op za 05-03-2022 om 16:13 [-0500]:
>>> On Thu, Mar 03, 2022 at 07:25:22AM +0100, Maxime Devos wrote:
>>> > Leo Famulari schreef op wo 02-03-2022 om 18:50 [-0500]:
>>> > > Origin snippets should only be used to remove nonfree things
>>> > > from the upstream source code. All other changes should use
>>> > > patch files or a build phase.
>>> > Why? If it's a source code change and it fits an origin snippet,
>>> > why not an origin snippet? Why would the source in Guix need to
>>> > the source upstream?
>>> `guix build --source` is a tool to provide freely licensed source
>>> to be used for any purpose, including building on systems besides
>>> Using the Guix tools, there is no way to access the upstream source
>>> without applying the snippets. The reason for that is that the origin
>>> snippet mechanism was introduced specifically to remove non-free
>>> components without making it easy to reverse the transformation.
>> It might be introduced for removing non-free components, that doesn't
>> mean it cannot be used for more. Also, I don't see the point of ease
>> of reversing here. It's trivial to reverse the transformation induced
>> by the snippet: just delete the snippet in a git checkout.
> Well, the point is the FSDG  frame, I guess. From my understanding,
> when --source had been introduced, it was a countermeasure to be able to
> use hybrid source and still be compliant with an interpretation of: «A
> free system distribution must not steer users towards obtaining any
> nonfree information for practical use, or encourage them to do so.»
> Therefore, using Guix tools, e.g., guix build --source, it is not easy
> to reverse what ’snippet’ does.
> I would not say it is trivial to reverse the transformation because the
> user needs to run “guix edit”, then reassemble the URL, then fetch.
> Otherwise, yes the user could go to the Guix repo, remove the snippet,
> then run “guix shell -D guix”, do somehow “./pre-inst-env guix …”.
> Well, I do not consider these steps “trivial”. And if one user does
> that, somehow they really want to obtain nonfree information. :-)
> 1: <https://www.gnu.org/distros/free-system-distribution-guidelines.en.html>
>>> Compare that to patch files, which are easily reversed,
>> Removing a patch file by removing it from the 'patches' field is easy,
>> as easy as removing a snippet. I assume you meant the additional
>> condition ‘... using only CLI tools’?
> Yes, somehow.
>> I am aware of the guideline of keeping the source usable outside Guix
>> systems. AFAICT, in this case, the snippet modifying
>> Makefile.am/Makefile.in keeps the source usable on non-Guix systems.
>> In fact, it makes the source _more_ usable, both on Guix and non-Guix,
>> by working-around a Guile 3.0.5 compiler bug. So I don't see any
>> problems here.
> Well, the question without consensus is what “guix build --source”
> should return?
> a) The source of what “guix build” concretely builds?
> b) The source of upstream (modulo the removal of nonfree part)?
> The aim is to be as close as possible as b), IMHO. The exception of
> patches could be discussed. :-)
> Back to Shepherd, because the question is originally from patch#54216
> , the initial snippet was turning a flag:
> + (snippet
> + '(begin
> + ;; Build with -O1 to work around <https://bugs.gnu.org/48368>.
> + (substitute* "Makefile.am"
> + (("compile --target")
> + "compile -O1 --target"))))))
> Somehow, the snippet could be considered as a “patch“. And, in the same
> time, the upstream source will not compile without this ’-O1’, IIUC.
> However, since “we“ are in the same time upstream and downstream, we
> could fix that without introducing this kind of snippet.
> Last, because the package is for building with Guix, then it seems more
> appropriate to have the substitution in the ’arguments’, as v3  is
> 2: <http://issues.guix.gnu.org/issue/54216>
> 3: <https://issues.guix.gnu.org/issue/54216#19>
Retrieve my PGP public key:
gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F
Description: PGP signature
|[Prev in Thread]
||[Next in Thread]|
- Re: gnu: shepherd: patch, snippet or phase,
Zhu Zihao <=