[bug#65550] [PATCH] profiles: Don't propagate inputs for non-development packages.

["宋文武 via Guix-patches via" <guix-patches@gnu.org>]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Samstag, dem 26.08.2023 um 21:53 +0800 schrieb iyzsong@envs.net:
>> From: 宋文武 <iyzsong@member.fsf.org>
>> 
>> * guix/profiles.scm (package->manifest-entry): Only include
>> propagated inputs from a package for its "dev" output, or its "out"
>> output if the package doesn't have a "dev" one.
>> ---
> I think this patch misses the most obvious use case of the out:lib
> split.  I also think that hardcoding this list is bound to fail.

Ah, that's true.  We currently put both headers and pkgconfig files in
the "lib" output, I think we should put those files into "dev" instead,
only leave shared libraries in "lib" (then we don't need propagated it
anymore).

And I did a test to find packages with "lib" and propagated-inputs:
--8<---------------cut here---------------start------------->8---
(use-modules (gnu packages)
             (guix packages)
             (srfi srfi-1)
             (ice-9 pretty-print))

(define x
  (delete-duplicates
   (fold-packages
    (lambda (package result)
      (if (and (member "lib" (package-outputs package))
               (not (null? (package-propagated-inputs package))))
          (cons (package-name package) result)
          result))
    '())))

(pretty-print x)
--8<---------------cut here---------------end--------------->8---
Only hwloc and apache-arrow, and 24 packages (uniqued by name) have
a "lib" output, seems doable.


> Instead, we could for the time being solve this with yet another
> package property.
>   '((propagate-inputs-from "lib")) ; but not out
>   '((propagate-inputs-from . ("lib"))) ; same meaning, different style
>   '((propagate-inputs-from "out" "lib")) ; but not doc
> If the property is missing, we still propagate from all outputs, as is
> currently done.
>
> WDYT?

Yes, a property is more flexible here, haven't think about it.  Well I
wishful think if we always follow a good convention (put development
files in "dev" or "out"), then maybe we can saving some bytes in code?
I'd like to split more packages with multiple outputs with "dev" to see
how the convention works out.  If not then we could take this 'property'
way.

Thanks!