Grafting prevents build plan from being displayed upfront

  • Done
  • quality assurance status badge
Details
2 participants
  • Andreas Enge
  • Ludovic Courtès
Owner
unassigned
Submitted by
Andreas Enge
Severity
important
A
A
Andreas Enge wrote on 31 Aug 2017 21:03
guix build -n misses package builds
(address . bug-guix@gnu.org)
20170831190334.GA6673@jurong
Hello,

I am right now in the process of updating pari-gp to version 2.9.3.
After building it on a git check-out of three days ago, which went smoothly,
I rebased my patch on today's master and was pleased to see that no rebuild
was needed:

$ ./pre-inst-env guix build pari-gp -n
outputs nothing.

However, once the -n dropped, the gd package gets built.
And then it is starting ruby, which has no connection to pari-gp:
ruby-2.4.1.tar.xz 9.5MiB 22KiB/s 00:06 [ ] 1.3%^

Andreas
L
L
Ludovic Courtès wrote on 2 Sep 2017 01:03
control message for bug #28310
(address . control@debbugs.gnu.org)
87h8wmxbqh.fsf@gnu.org
retitle 28310 Grafting prevents build plan from being displayed upfront
L
L
Ludovic Courtès wrote on 2 Sep 2017 01:08
Re: bug#28310: guix build -n misses package builds
(name . Andreas Enge)(address . andreas@enge.fr)(address . 28310@debbugs.gnu.org)
87a82exbj7.fsf@gnu.org
Hello,

Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (13 lines)
> I am right now in the process of updating pari-gp to version 2.9.3.
> After building it on a git check-out of three days ago, which went smoothly,
> I rebased my patch on today's master and was pleased to see that no rebuild
> was needed:
>
> $ ./pre-inst-env guix build pari-gp -n
> outputs nothing.
>
> However, once the -n dropped, the gd package gets built.
> And then it is starting ruby, which has no connection to pari-gp:
> Downloading https://mirror.hydra.gnu.org/guix/nar/229n3pzp5bdmbdvwslg0dxliysas92k5-ruby-2.4.1.tar.xz...
> ruby-2.4.1.tar.xz 9.5MiB 22KiB/s 00:06 [ ] 1.3%^

“-n” now implies “--no-grafts” (commit
fd59105c49965db956fac73c68d8b00d068f5d5c). This was motivated by the
need to have -n really perform a dry run.

The downside is that with -n we now see only half of the build plan, and
when we remove -n, we start with the other half of the build plan,
grafting.

The “build continuation” idea of ‘wip-gexp-grafts’, discussed in
https://bugs.gnu.org/22990, could in theory help with that.

Ludo’.
A
A
Andreas Enge wrote on 2 Sep 2017 12:04
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 28310@debbugs.gnu.org)
20170902100400.GA1917@jurong
Hello,

On Sat, Sep 02, 2017 at 01:08:12AM +0200, Ludovic Courtès wrote:
Toggle quote (4 lines)
> “-n” now implies “--no-grafts” (commit
> fd59105c49965db956fac73c68d8b00d068f5d5c). This was motivated by the
> need to have -n really perform a dry run.

if I understand your answer correctly, then no output with "-n" means that
the ungrafted packages are already available in my store.

Toggle quote (4 lines)
> The downside is that with -n we now see only half of the build plan, and
> when we remove -n, we start with the other half of the build plan,
> grafting.

Then this other half would just be grafting, which would not require to
download source and build packages locally.

Or are the built packages the replacements for packages with security
updates, that are grafted upon the existing packages?

Andreas
L
L
Ludovic Courtès wrote on 2 Sep 2017 22:13
(name . Andreas Enge)(address . andreas@enge.fr)(address . 28310@debbugs.gnu.org)
871snoyi37.fsf@gnu.org
Hi,

Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (8 lines)
> On Sat, Sep 02, 2017 at 01:08:12AM +0200, Ludovic Courtès wrote:
>> “-n” now implies “--no-grafts” (commit
>> fd59105c49965db956fac73c68d8b00d068f5d5c). This was motivated by the
>> need to have -n really perform a dry run.
>
> if I understand your answer correctly, then no output with "-n" means that
> the ungrafted packages are already available in my store.

Exactly.

Toggle quote (7 lines)
>> The downside is that with -n we now see only half of the build plan, and
>> when we remove -n, we start with the other half of the build plan,
>> grafting.
>
> Then this other half would just be grafting, which would not require to
> download source and build packages locally.

Grafting usually means downloading/building the replacements first, and
finally performing the actual graft.

I agree it makes it harder to follow from a user viewpoint.

Cheers,
Ludo’.
A
A
Andreas Enge wrote on 7 Sep 2017 14:42
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 28310-done@debbugs.gnu.org)
20170907124255.GA1405@jurong
On Sat, Sep 02, 2017 at 01:08:12AM +0200, Ludovic Courtès wrote:
Toggle quote (11 lines)
> “-n” now implies “--no-grafts” (commit
> fd59105c49965db956fac73c68d8b00d068f5d5c). This was motivated by the
> need to have -n really perform a dry run.
>
> The downside is that with -n we now see only half of the build plan, and
> when we remove -n, we start with the other half of the build plan,
> grafting.
>
> The “build continuation” idea of ‘wip-gexp-grafts’, discussed in
> <https://bugs.gnu.org/22990>, could in theory help with that.

Okay, so to simplify, I am closing this bug report.

Andreas
Closed
L
L
Ludovic Courtès wrote on 7 Sep 2017 15:23
control message for bug #28310
(address . control@debbugs.gnu.org)
87fubywsll.fsf@gnu.org
severity 28310 important
L
L
Ludovic Courtès wrote on 7 Sep 2017 15:24
Re: bug#28310: guix build -n misses package builds
(name . Andreas Enge)(address . andreas@enge.fr)(address . 28310@debbugs.gnu.org)
87bmmmwsjy.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (14 lines)
> On Sat, Sep 02, 2017 at 01:08:12AM +0200, Ludovic Courtès wrote:
>> “-n” now implies “--no-grafts” (commit
>> fd59105c49965db956fac73c68d8b00d068f5d5c). This was motivated by the
>> need to have -n really perform a dry run.
>>
>> The downside is that with -n we now see only half of the build plan, and
>> when we remove -n, we start with the other half of the build plan,
>> grafting.
>>
>> The “build continuation” idea of ‘wip-gexp-grafts’, discussed in
>> <https://bugs.gnu.org/22990>, could in theory help with that.
>
> Okay, so to simplify, I am closing this bug report.

I’ve reopened it (it’s a real problem after all) so we can keep track of
it, and feel the relief when we finally close it. :-)

Ludo’.
L
L
Ludovic Courtès wrote on 22 Mar 2020 12:48
(name . Andreas Enge)(address . andreas@enge.fr)(address . 28310-done@debbugs.gnu.org)
87bloovcdk.fsf@gnu.org
Hello,

ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (23 lines)
> Andreas Enge <andreas@enge.fr> skribis:
>
>> I am right now in the process of updating pari-gp to version 2.9.3.
>> After building it on a git check-out of three days ago, which went smoothly,
>> I rebased my patch on today's master and was pleased to see that no rebuild
>> was needed:
>>
>> $ ./pre-inst-env guix build pari-gp -n
>> outputs nothing.
>>
>> However, once the -n dropped, the gd package gets built.
>> And then it is starting ruby, which has no connection to pari-gp:
>> Downloading https://mirror.hydra.gnu.org/guix/nar/229n3pzp5bdmbdvwslg0dxliysas92k5-ruby-2.4.1.tar.xz...
>> ruby-2.4.1.tar.xz 9.5MiB 22KiB/s 00:06 [ ] 1.3%^
>
> “-n” now implies “--no-grafts” (commit
> fd59105c49965db956fac73c68d8b00d068f5d5c). This was motivated by the
> need to have -n really perform a dry run.
>
> The downside is that with -n we now see only half of the build plan, and
> when we remove -n, we start with the other half of the build plan,
> grafting.

This is now fixed with this patch series:


It does mean that “The following derivations will be built” can be
printed several times during a build. That’s a natural consequence of
having dynamic dependencies (grafts) in the graph: we can’t always
statically determine what’s going to be built.

Toggle quote (3 lines)
> The “build continuation” idea of ‘wip-gexp-grafts’, discussed in
> <https://bugs.gnu.org/22990>, could in theory help with that.

‘with-build-handler’ also has to do with continuations, only in a
different way. :-)

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 28310@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 28310
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch