Reverse dependencies

Reverse dependencies

[Vincent Legoll]

Hello,

I'm trying to understand which package(s) depends on some other package,
kind of the reverse of what guix graph does (I think).

-- 
Vincent Legoll

Re: Reverse dependencies

[Leo Famulari]

On Sat, Jul 16, 2016 at 11:58:51AM +0200, Vincent Legoll wrote:
> Hello,
> 
> I'm trying to understand which package(s) depends on some other package,
> kind of the reverse of what guix graph does (I think).

I think that `guix refresh --list-dependent foo` is what you are asking
for, or at least it's close. We use it to learn what will need to be
rebuilt when upgrading foo.

Re: Reverse dependencies

[Vincent Legoll]

Hello,

>> I'm trying to understand which package(s) depends on some other package,
>> kind of the reverse of what guix graph does (I think).
>
> I think that `guix refresh --list-dependent foo` is what you are asking
> for, or at least it's close. We use it to learn what will need to be
> rebuilt when upgrading foo.

Not really what I want to know:

# guix refresh --list-dependent inkscape
Building the following 5 packages would ensure 10 dependent packages
are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
termite-11 hydra-20150407.4c0e3e4

None of those are installed, but inkscape is pulled in by something
which I want to know

Is there no other way to get that information ?

-- 
Vincent Legoll

Re: Reverse dependencies

[Patricia J. Hawkins]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]


>>>>> "VL" == Vincent Legoll <vincent.legoll@gmail.com> writes:

VL> Hello,
>>> I'm trying to understand which package(s) depends on some other package,
>>> kind of the reverse of what guix graph does (I think).
>> 
>> I think that `guix refresh --list-dependent foo` is what you are asking
>> for, or at least it's close. We use it to learn what will need to be
>> rebuilt when upgrading foo.

VL> Not really what I want to know:

VL> # guix refresh --list-dependent inkscape
VL> Building the following 5 packages would ensure 10 dependent packages
VL> are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
VL> termite-11 hydra-20150407.4c0e3e4

VL> None of those are installed, but inkscape is pulled in by something
VL> which I want to know

VL> Is there no other way to get that information ?

Synaptic has this capability, I expect the code could be
reused. It is indeed handy to have. 

Attached is a screenshot of the packages that have inkscape as a
dependency, as of the latest upgrade of Ubuntu 14.04.5 (Trusty tahr.) 


[-- Attachment #2: Packages that depend on inkscape --]
[-- Type: image/png, Size: 60648 bytes --]

[-- Attachment #3: Type: text/plain, Size: 31 bytes --]


HTH. 
-- 
Patricia J. Hawkins

Re: Reverse dependencies

[Eric Bavier]

On 2016-08-11 09:43, Vincent Legoll wrote:
> Hello,
> 
>>> I'm trying to understand which package(s) depends on some other 
>>> package,
>>> kind of the reverse of what guix graph does (I think).
>> 
>> I think that `guix refresh --list-dependent foo` is what you are 
>> asking
>> for, or at least it's close. We use it to learn what will need to be
>> rebuilt when upgrading foo.
> 
> Not really what I want to know:
> 
> # guix refresh --list-dependent inkscape
> Building the following 5 packages would ensure 10 dependent packages
> are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
> termite-11 hydra-20150407.4c0e3e4
> 
> None of those are installed, but inkscape is pulled in by something
> which I want to know
> 
> Is there no other way to get that information ?

Something like (mildly tested):

(use-modules (guix packages)
              (gnu packages)
              (gnu packages inkscape)
              (srfi srfi-1)
              (srfi srfi-26))

(fold-packages
   (lambda (package _)
     (when (any (cut eq? <> inkscape)
                (map second (package-direct-inputs package)))
       (format #t "~a depends on inkscape~%"
               (package-full-name package))))
   #t)

which, when run, results in:
"dblatex-0.3.5 depends on inkscape"

-- 
`~Eric

Re: Reverse dependencies

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]

Eric Bavier <ericbavier@openmailbox.org> writes:

> On 2016-08-11 09:43, Vincent Legoll wrote:
>> Hello,
>>
>>>> I'm trying to understand which package(s) depends on some other
>>>> package,
>>>> kind of the reverse of what guix graph does (I think).
>>>
>>> I think that `guix refresh --list-dependent foo` is what you are
>>> asking
>>> for, or at least it's close. We use it to learn what will need to be
>>> rebuilt when upgrading foo.
>>
>> Not really what I want to know:
>>
>> # guix refresh --list-dependent inkscape
>> Building the following 5 packages would ensure 10 dependent packages
>> are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
>> termite-11 hydra-20150407.4c0e3e4
>>
>> None of those are installed, but inkscape is pulled in by something
>> which I want to know
>>
>> Is there no other way to get that information ?
>
> Something like (mildly tested):
>
> (use-modules (guix packages)
>              (gnu packages)
>              (gnu packages inkscape)
>              (srfi srfi-1)
>              (srfi srfi-26))
>
> (fold-packages
>   (lambda (package _)
>     (when (any (cut eq? <> inkscape)
>                (map second (package-direct-inputs package)))
>       (format #t "~a depends on inkscape~%"
>               (package-full-name package))))
>   #t)
>
> which, when run, results in:
> "dblatex-0.3.5 depends on inkscape"

The 'guix graph' command has the ability to print out references, but my
understanding is that because these are the references which result from
Nix's scan of the output store path, these references will only be
runtime dependencies (see '(guix) Invoking guix graph' in the manual).

The 'guix gc' command has the ability to print out 'referrers', which
might also be useful.  See '(guix) Invoking guix gc' for details.  This
will show you components that refer to the specified store path.

I also hear that the Nix daemon can be configured to maintain a database
of derivers, which would let you find out which derivation generated a
given store path.  I don't know if Guix enables this by default.  If
it's enabled, then you could potentially investigate the derivation
which generated a store path (e.g., to see if the derivation references
inkscape), but I don't know of any automated tools for investigating
that stuff today.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Reverse dependencies

[Eric Bavier]

On 2016-08-12 11:24, Chris Marusich wrote:
> Eric Bavier <ericbavier@openmailbox.org> writes:
> 
>> On 2016-08-11 09:43, Vincent Legoll wrote:
>>> Hello,
>>> 
>>>>> I'm trying to understand which package(s) depends on some other
>>>>> package,
>>>>> kind of the reverse of what guix graph does (I think).
>>>> 
>>>> I think that `guix refresh --list-dependent foo` is what you are
>>>> asking
>>>> for, or at least it's close. We use it to learn what will need to be
>>>> rebuilt when upgrading foo.
>>> 
>>> Not really what I want to know:
>>> 
>>> # guix refresh --list-dependent inkscape
>>> Building the following 5 packages would ensure 10 dependent packages
>>> are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
>>> termite-11 hydra-20150407.4c0e3e4
>>> 
>>> None of those are installed, but inkscape is pulled in by something
>>> which I want to know
>>> 
>>> Is there no other way to get that information ?
>> 
>> Something like (mildly tested):
>> 
>> (use-modules (guix packages)
>>              (gnu packages)
>>              (gnu packages inkscape)
>>              (srfi srfi-1)
>>              (srfi srfi-26))
>> 
>> (fold-packages
>>   (lambda (package _)
>>     (when (any (cut eq? <> inkscape)
>>                (map second (package-direct-inputs package)))
>>       (format #t "~a depends on inkscape~%"
>>               (package-full-name package))))
>>   #t)
>> 
>> which, when run, results in:
>> "dblatex-0.3.5 depends on inkscape"
> 
> The 'guix graph' command has the ability to print out references, but 
> my
> understanding is that because these are the references which result 
> from
> Nix's scan of the output store path, these references will only be
> runtime dependencies (see '(guix) Invoking guix graph' in the manual).

This is not completely accurate.  'guix graph's '--type' argument can be 
used to display different node types.  The 'references' type corresponds 
to run-time dependencies.

-- 
`~Eric

Re: Reverse dependencies

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

Eric Bavier <ericbavier@openmailbox.org> writes:

> On 2016-08-12 11:24, Chris Marusich wrote:
>> Eric Bavier <ericbavier@openmailbox.org> writes:
>>
>>> On 2016-08-11 09:43, Vincent Legoll wrote:
>>>> Hello,
>>>>
>>>>>> I'm trying to understand which package(s) depends on some other
>>>>>> package,
>>>>>> kind of the reverse of what guix graph does (I think).
>>>>>
>>>>> I think that `guix refresh --list-dependent foo` is what you are
>>>>> asking
>>>>> for, or at least it's close. We use it to learn what will need to be
>>>>> rebuilt when upgrading foo.
>>>>
>>>> Not really what I want to know:
>>>>
>>>> # guix refresh --list-dependent inkscape
>>>> Building the following 5 packages would ensure 10 dependent packages
>>>> are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
>>>> termite-11 hydra-20150407.4c0e3e4
>>>>
>>>> None of those are installed, but inkscape is pulled in by something
>>>> which I want to know
>>>>
>>>> Is there no other way to get that information ?
>>>
>>> Something like (mildly tested):
>>>
>>> (use-modules (guix packages)
>>>              (gnu packages)
>>>              (gnu packages inkscape)
>>>              (srfi srfi-1)
>>>              (srfi srfi-26))
>>>
>>> (fold-packages
>>>   (lambda (package _)
>>>     (when (any (cut eq? <> inkscape)
>>>                (map second (package-direct-inputs package)))
>>>       (format #t "~a depends on inkscape~%"
>>>               (package-full-name package))))
>>>   #t)
>>>
>>> which, when run, results in:
>>> "dblatex-0.3.5 depends on inkscape"
>>
>> The 'guix graph' command has the ability to print out references,
>> but my
>> understanding is that because these are the references which result
>> from
>> Nix's scan of the output store path, these references will only be
>> runtime dependencies (see '(guix) Invoking guix graph' in the manual).
>
> This is not completely accurate.  'guix graph's '--type' argument can
> be used to display different node types.  The 'references' type
> corresponds to run-time dependencies.

I see!  Thank you for the additional information.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Reverse dependencies

[Alex Kost]

Vincent Legoll (2016-08-11 17:43 +0300) wrote:

> Hello,
>
>>> I'm trying to understand which package(s) depends on some other package,
>>> kind of the reverse of what guix graph does (I think).
>>
>> I think that `guix refresh --list-dependent foo` is what you are asking
>> for, or at least it's close. We use it to learn what will need to be
>> rebuilt when upgrading foo.
>
> Not really what I want to know:
>
> # guix refresh --list-dependent inkscape
> Building the following 5 packages would ensure 10 dependent packages
> are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
> termite-11 hydra-20150407.4c0e3e4
>
> None of those are installed, but inkscape is pulled in by something
> which I want to know

I think you mean inkscape is pulled when you build the system.  Then you
will not find it like this.  It is needed to build the fancy grub image,
and it is "pulled" by the system building code (specifically by
'svg->png' procedure in (gnu system grub) module).  If you want to avoid
it, you can specify an "empty" theme for example:

  (bootloader (grub-configuration (device "/dev/sda")
                                  (theme (grub-theme))))

-- 
Alex

Re: Reverse dependencies

[Vincent Legoll]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

Hello,

> I think you mean inkscape is pulled when you build the system.  Then you
> will not find it like this.  It is needed to build the fancy grub image,
> and it is "pulled" by the system building code (specifically by
> 'svg->png' procedure in (gnu system grub) module).  If you want to avoid
> it, you can specify an "empty" theme for example:
>
>   (bootloader (grub-configuration (device "/dev/sda")
>                                   (theme (grub-theme))))

Thanks for that information, that was what I wanted to know (both the where
does it come from, and the how to avoid it being pulled in)

I think a "guix revdep $PKG" should be a valuable tool

it should work:
1 - globally in the list of defined packages
2 - locally in the list of packages from the current user's profile
3 - systemly, from the list of installed packages in the system profile

I'm trying Eric's suggestion (thanks Eric), and that seems to do 1, I need
a way to modify it to do the other 2... (see the attached script)

WDYT ?

-- 
Vincent Legoll

[-- Attachment #2: revdep.scm --]
[-- Type: text/x-scheme, Size: 1957 bytes --]

;;; GNU Guix --- Functional package management for GNU
;;; Copyright <C2><A9> 2016 Vincent Legoll <vincent.legoll@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(use-modules (guix packages)
             (gnu packages)
             (srfi srfi-1)
             (srfi srfi-26)
             (ice-9 getopt-long))
 	
(define (revdep pkg)
  (fold-packages
    (lambda (package _)
      (when (any (cut eq? <> (specification->package pkg))
                 (map second (package-direct-inputs package)))
        (format #t "~a depends on ~a~%"
                (package-full-name package) pkg)))
    #t))

(define (main args)
  (let* ((option-spec '((version (single-char #\v) (value #f))
                        (help    (single-char #\h) (value #f))))
         (options (getopt-long args option-spec))
         (help-wanted (option-ref options 'help #f))
         (version-wanted (option-ref options 'version #f))
         (pkgs (option-ref options '() #f)))
    (if (or version-wanted help-wanted)
        (begin
          (if version-wanted
              (display "revdep.scm version 0.1\n"))
          (if help-wanted
              (display "\
revdev.scm [options|package names]
  -v, --version    Display version
  -h, --help       Display this help\n")))
        (map revdep pkgs))))

(main (command-line))

Re: Reverse dependencies

[Thompson, David]

On Fri, Aug 12, 2016 at 5:27 AM, Vincent Legoll
<vincent.legoll@gmail.com> wrote:
> Hello,
>
>> I think you mean inkscape is pulled when you build the system.  Then you
>> will not find it like this.  It is needed to build the fancy grub image,
>> and it is "pulled" by the system building code (specifically by
>> 'svg->png' procedure in (gnu system grub) module).  If you want to avoid
>> it, you can specify an "empty" theme for example:
>>
>>   (bootloader (grub-configuration (device "/dev/sda")
>>                                   (theme (grub-theme))))
>
> Thanks for that information, that was what I wanted to know (both the where
> does it come from, and the how to avoid it being pulled in)
>
> I think a "guix revdep $PKG" should be a valuable tool

While we can certainly make learning about this stuff easier, but
making a new subcommand with a cryptic name just for this purpose
wouldn't be a very good UI.

> it should work:
> 1 - globally in the list of defined packages
> 2 - locally in the list of packages from the current user's profile
> 3 - systemly, from the list of installed packages in the system profile

What do you define "dependencies" to be?  Using your situation as an
example, inkscape is *not* a dependency of the built system, but it is
a dependency of the *derivation* that builds the system.  Using
profiles wouldn't work because profiles may contain references to
store items that the current Guix has no knowledge of.  package
expression -> built package is a one way transformation.  What you can
do, however, is use 'guix gc --referrers' to get a list of store items
that refer to the store item passed in.  This still doesn't help you
in the inkscape case because the built system has no reference to
inkscape, it was just used in the build script.

I think the "right thing" here is to add features to 'guix graph' so
that it can make a referrer graph using the Scheme package graph.
'guix system' has graph subcommands already, so we could add one that
produces a full package dependency graph which would show you who
depends on inkscape.

Any volunteers? :)

I'd also like to point out that you can already use 'guix gc
--referrers /gnu/store/....-foo-1.0' to find out which store items
depend on the one passed in.

- Dave

Re: Reverse dependencies

[Thompson, David]

On Fri, Aug 12, 2016 at 11:55 AM, Thompson, David
<dthompson2@worcester.edu> wrote:

> I'd also like to point out that you can already use 'guix gc
> --referrers /gnu/store/....-foo-1.0' to find out which store items
> depend on the one passed in.

I realize this is redundant with what I wrote above.  Hasty writing...
Sorry for the noise.

- Dave

Re: Reverse dependencies

[Vincent Legoll]

Hello,

> What do you define "dependencies" to be?  Using your situation as an
> example, inkscape is *not* a dependency of the built system, but it is
> a dependency of the *derivation* that builds the system.

I don't know which exact terms to use, I just wanted to avoid pulling in
a big GUI package when I chose a bare-bones system, since I had to
compile it a few times while hydra was recovering. I always have seen
the term "reverse dependencies" used to refer to that concept.

> I'd also like to point out that you can already use 'guix gc
> --referrers /gnu/store/....-foo-1.0' to find out which store items
> depend on the one passed in.

I expected gc to mean "garbage collect" and do just that. As a newcomer
I'd never have searched there, and even then, that would not have helped :

$ guix help gc
Usage: guix gc [OPTION]... PATHS...
Invoke the garbage collector.
[...]
      --references       list the references of PATHS
  -R, --requisites       list the requisites of PATHS
      --referrers        list the referrers of PATHS

The reference manual has more detailed explanations, maybe this
should be copied in "guix help gc".

WDYT ?

-- 
Vincent Legoll