The new patch method and mit-krb5

The new patch method and mit-krb5

[Mark H Weaver]

Hello all,

A patch is needed to allow mit-krb5 to build on MIPS N32.  However, the
new method, where 'patches' is part of 'origin', does not work for
mit-krb5.

mit-krb5 is distributed in a strange way.  It's distributed as a tar
file that contains two files: a .tar.gz file with the actual source
code, and a signature for that .tar.gz file.  The mit-krb5 recipe copes
with this by using a custom 'unpack' phase.

My working patch is now on the 'loongson' branch:

  http://git.savannah.gnu.org/cgit/guix.git/commit/?h=loongson&id=db956e3aff4ea5d39fb45a5a1079f8b24a592c29

Can someone help me convert this to use the new patch method?
We'll need a solution before the old patch method goes away.

     Thanks,
       Mark

Re: The new patch method and mit-krb5

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> A patch is needed to allow mit-krb5 to build on MIPS N32.  However, the
> new method, where 'patches' is part of 'origin', does not work for
> mit-krb5.
>
> mit-krb5 is distributed in a strange way.  It's distributed as a tar
> file that contains two files: a .tar.gz file with the actual source
> code, and a signature for that .tar.gz file.  The mit-krb5 recipe copes
> with this by using a custom 'unpack' phase.

The new method won’t work in this case.

Thus, the patch has to be applied manually with

  (system* "patch" "-p1" "--batch" "-i" ...)

in the custom ‘unpack’ phase.

HTH,
Ludo’.

Re: The new patch method and mit-krb5

[Andreas Enge]

On Wed, Oct 30, 2013 at 04:35:26PM +0100, Ludovic Courtès wrote:
> The new method won’t work in this case.
> Thus, the patch has to be applied manually with

Alternatively, could we modify
   (guix packages patch-and-repack)
so that instead of calling "tar" directly, it executes the phase named 'unpack
of the package? After that, it would apply the patches and repackage.

This would be more flexible. For instance, we could use it to derive a udev
source tarball out of the systemd sources, which would then be returned via
   guix build udev -S

Andreas

Re: The new patch method and mit-krb5

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Oct 30, 2013 at 04:35:26PM +0100, Ludovic Courtès wrote:
>> The new method won’t work in this case.
>> Thus, the patch has to be applied manually with
>
> Alternatively, could we modify
>    (guix packages patch-and-repack)
> so that instead of calling "tar" directly, it executes the phase named 'unpack
> of the package? After that, it would apply the patches and repackage.

The notion of phases is internal to the build system, so we can’t really
do that.

What we could do is to add a ‘snippet’ field in <origin> where users
could provide an expression to use as the patch phase.

> This would be more flexible. For instance, we could use it to derive a udev
> source tarball out of the systemd sources, which would then be returned via
>    guix build udev -S

Nice example.  ;-)

Though I suppose this case is easily addressed with just (chdir "udev")
or something similar no?

Ludo’.

Re: The new patch method and mit-krb5

[Andreas Enge]

On Wed, Oct 30, 2013 at 07:15:32PM +0100, Ludovic Courtès wrote:
> The notion of phases is internal to the build system, so we can’t really
> do that.

Well, the phases are part of the package object. So should it not be able
to extract them? Or does the source field not have any access to the
arguments field? We might distinguish the case that there is a phase
argument inside the arguments field (in which case we extract 'unpack)
from the usual case where nothing is specified and we do the usual thing.

> > This would be more flexible. For instance, we could use it to derive a udev
> > source tarball out of the systemd sources, which would then be returned via
> >    guix build udev -S
> Nice example.  ;-)
> Though I suppose this case is easily addressed with just (chdir "udev")
> or something similar no?

No idea, I did not have a look at it.

Andreas

Re: The new patch method and mit-krb5

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Oct 30, 2013 at 07:15:32PM +0100, Ludovic Courtès wrote:
>> The notion of phases is internal to the build system, so we can’t really
>> do that.
>
> Well, the phases are part of the package object. So should it not be able
> to extract them? Or does the source field not have any access to the
> arguments field?

First <origin> objects are distinct from <package> object, and there’s
no connection from the <origin> to the containing <package> (if any).

Second, the ‘arguments’ field is passed as-is, uninterpreted, to the
build system.  And most of the time the ‘arguments’ field has no
#:phases argument anyway.

Just to say that the current design wouldn’t lend itself to this sort of
thing.

Perhaps phases should be a more fundamental thing, imposed on all build
systems, but thinking through such a change would require a stronger
incentive, IMO.  :-)

Thanks,
Ludo’.

Re: The new patch method and mit-krb5

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:
> What we could do is to add a ‘snippet’ field in <origin> where users
> could provide an expression to use as the patch phase.

How about adding a 'snippet' field to <origin> where users could provide
an expression to use as the _unpack_ phase?  That's really what we need
here, and it would be nice to support things other than 'tar'.

I suppose another option would be to make another derivation whose sole
purpose is to extract the actual source tarball out of the second-level
tarball (which for 'mit-krb5' contains both the source tarball and the
signature).  However, I'm not sure how to make the 'mit-krb5' package
description use the results of this other derivation as the source
tarball.

Ideas welcome.

     Thanks,
       Mark

Re: The new patch method and mit-krb5

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>> What we could do is to add a ‘snippet’ field in <origin> where users
>> could provide an expression to use as the patch phase.
>
> How about adding a 'snippet' field to <origin> where users could provide
> an expression to use as the _unpack_ phase?  That's really what we need
> here, and it would be nice to support things other than 'tar'.

Well, looking at the code, I see that any changes there are likely to
result in a full rebuild.  I pushed a new mit-krb5 fix to core-updates,
and it was quite easy, so maybe it's not worth worrying about this
anytime soon.  There are far more important jobs to work on.

     Thanks,
       Mark

Re: The new patch method and mit-krb5

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>> What we could do is to add a ‘snippet’ field in <origin> where users
>> could provide an expression to use as the patch phase.
>
> How about adding a 'snippet' field to <origin> where users could provide
> an expression to use as the _unpack_ phase?  That's really what we need
> here, and it would be nice to support things other than 'tar'.

Currently the ‘unpack’ phase is done by the build system.  We could
imagine feeding the build system with a directory instead of a tarball,
and thus handling the unpacking in an intermediate derivation.

However that would make things more complex (esp. during bootstrapping),
and I’m not sure it’s really needed.

Anyway, if we do find that it’s really needed in the future, we can
revisit that (after 0.5, that is ;-)).

Ludo’.