Re: [PATCH] list-packages: Display package usage count.

[ludo@gnu.org (Ludovic Courtès)]

Eric Bavier <ericbavier@gmail.com> skribis:

> Mark H Weaver writes:
>
>> Eric Bavier <ericbavier@gmail.com> writes:
>>
>>> Ludovic Courtès writes:
>>>
>>>> Eric Bavier <ericbavier@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.

In the examples Mark gave, the various packages use the same origin.  I
think a good fix would be to somehow map <origin> objects to packages
that refer to them.

However, that seems mostly useful to ‘guix refresh -l’, and not really
for list-packages.scm.  WDYT?

>> 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).

That’s an option, but I’d like to avoid going this far.  Notably because
it might lead to a growth in heap usage as ancestors would remain
reachable, but also because I feel we may not be looking at things from
the right angle.

Conceptually, there’s an object DAG and we’re trying to enumerate the
those that depend on a given object.  What you did works well for
package objects, but ignores edges in the DAG between a package and an
origin, or between a package and a file.  Perhaps the fix would be to
account for those edges?

Thanks,
Ludo’.