Mark H Weaver writes:
> Eric Bavier <ericbav...@gmail.com> writes:
>
>> Ludovic Courtès writes:
>>
>>> Eric Bavier <ericbav...@gmail.com> skribis:
>>>
>>>> + (define (users package)
>>>> + (let ((n (length (package-transitive-dependents
>>>> + (find-packages-by-name* (package-name package)
>>>> + (package-version
>>>> package))))))
>>>
>>> Why not just (package-transitive-dependents package)?
>>
>> Because that would not accurately count the "true" number of dependents.
>
> Agreed, but what you wrote doesn't fully address the problem either.
>
> If we modify 'gnu-make', that's also going to affect 'gnu-make-boot0' in
> commencement.scm. Since that one has a different name ("make-boot0"),
> your logic won't catch it.
>
> Similarly, if you modify 'gcc-4.7', that's also going to affect
> 'gcc-4.8' (different version) which affects 'gcc-boot0' (with a
> different name and version).
True. This is part of the reason the documentation for 'guix refresh
-l' notes the *approximate* accuracy of the reported dependents. The
yet-to-be-pushed rewrite with the bags api improves things, but doesn't
address these issues.
> So, it seems to me that we need a way to find all packages that
> 'inherit' from the package we're changing, transitively. I'm not sure
> off-hand if that information is preserved, but if not, we should
> probably arrange to preserve it somehow.
I was just thinking of this possibility earlier while working with 'guix
lint', regarding the patch-name warnings. Perhaps each package could
have an 'ancestor' field that is auto-populated when (inherit foo) is
used, and #f otherwise? That information could be included in the
DAG created by (package-dependencies).
--
Eric Bavier
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
