Why is die "doc" output downloaded when building this package?

Why is die "doc" output downloaded when building this package?

[Hartmut Goebel]

Hi,

when building this package, qt-4.8.7-doc (the doc-output of qt-4.7.8)
will be downloaded. I do not understand why.

  (package
    (name "automoc4")
    (version "0.9.88")
    (source (origin
      (method url-fetch)
      (uri (string-append
            "http://download.kde.org/stable/" name "/" version "/"
            name "-" version ".tar.xz"))
      (sha256
       (base32
          "0jackvg0bdjg797qlbbyf9syylm0qjs55mllhn11vqjsq3s1ch93"))))
    (build-system cmake-build-system)
    (arguments
     `(#:tests? #f))
    (inputs
     `(("qt-4" ,qt-4)))
    (home-page "http://kde.org/")
    (synopsis "")
    (description "")
    (license
license:gpl3+))                                                                             



-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Why is die "doc" output downloaded when building this package?

[Ludovic Courtès]

Hi,

(Adding a bug at bug-guix@gnu.org.)

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> when building this package, qt-4.8.7-doc (the doc-output of qt-4.7.8)
> will be downloaded. I do not understand why.

Most likely this is due to a limitation of the current implementation of
grafts: all the outputs of packages on a “grafting path” need to be
downloaded, even if some of these outputs are unused.

This is because ‘graft-derivation’ takes a derivation, such as Qt’s, and
returns a derivation with as many outputs, but marked as
non-substitutable (locally built).  Because it’s locally built, all the
outputs of the original derivation must be fetched just to be able to
build the grafted derivation, even if only one of those outputs is
needed.

I think we could fix that by creating one graft derivation for each
output of the original derivation.

Thanks,
Ludo’.

Re: Why is die "doc" output downloaded when building this package?

[Hartmut Goebel]

Am 05.11.2016 um 22:53 schrieb Ludovic Courtès:
> Most likely this is due to a limitation of the current implementation of
> grafts: all the outputs of packages on a “grafting path” need to be
> downloaded, even if some of these outputs are unused.

IC. Thanks for the explanation.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#24886: Why is die "doc" output downloaded when building this package?

[Ludovic Courtès]

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

> Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:
>
>> when building this package, qt-4.8.7-doc (the doc-output of qt-4.7.8)
>> will be downloaded. I do not understand why.
>
> Most likely this is due to a limitation of the current implementation of
> grafts: all the outputs of packages on a “grafting path” need to be
> downloaded, even if some of these outputs are unused.
>
> This is because ‘graft-derivation’ takes a derivation, such as Qt’s, and
> returns a derivation with as many outputs, but marked as
> non-substitutable (locally built).  Because it’s locally built, all the
> outputs of the original derivation must be fetched just to be able to
> build the grafted derivation, even if only one of those outputs is
> needed.
>
> I think we could fix that by creating one graft derivation for each
> output of the original derivation.

Done in 482fda2729c3e76999892cb8f9a0391a7bd37119.

To take a concrete example, “guix build brdf-explorer” would previously
trigger a download of qt:doc, even though only qt:out is used.  This is
no longer the case.

This commit does not fix situations like:

  guix package -i qt

In this case, qt:doc still gets downloaded for nothing.  This is because
the underlying

  (package-derivation store qt #:graft? #t)

call does not know that only “out” is needed.  This can be addressed
with “lazy grafting” as discussed in <https://bugs.gnu.org/22990>, where
we’d delay grafting until the profile is built instead of grafting each
individual package eagerly.

Ludo’.