Opened 3 years ago
Last modified 16 months ago
#64017 new enhancement
add a way to get rdeps of an installed version of a port
Reported by: | ballapete (Peter "Pete" Dyballa) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.7.1 |
Keywords: | Cc: | mascguy (Christopher Nielsen), ernstki (Kevin Ernst) | |
Port: |
Description
The command port rdeps gtk-doc
reports here:
The following ports are dependencies of gtk-doc @1.32_1+python39: xz libiconv gperf gettext ncurses pkgconfig glib2 libxml2 icu zlib meson py38-setuptools py-bootstrap-modules python38 bzip2 expat libedit libffi expect automake autoconf m4 tcl dejagnu openssl openssl3 sqlite3 python_select python3_select ninja re2c bison bison-runtime pcre libxslt docbook-xml xmlcatmgr docbook-xml-4.1.2 unzip docbook-xml-4.2 docbook-xml-4.3 docbook-xml-4.4 docbook-xml-4.5 docbook-xml-5.0 docbook-xsl-nons itstool gawk py38-libxml2 python39 py39-anytree py39-setuptools py39-six py39-pytest py39-setuptools_scm py39-packaging py39-parsing py39-pretend py39-tomli py39-attrs py39-hypothesis py39-sortedcontainers py39-zopeinterface py39-zope-event py39-nose nosetests_select py39-pip pip_select py39-iniconfig py39-pluggy py39-py py39-toml pytest_select py39-lxml py39-pygments pygments_select py39-mock
refers to some illusory port
named "gtk-doc @1.32₁+python39
". I have installed gtk-doc @1.32_1+pdf+python38
– why is port
not using the actually installed port
for reference? This behaviour would make more sense for me, when I try to find out why python39
gets installed when I am upgrading a port
, emacs-app-devel
for example. A help would be to use for example -i
or -d
to direct port rdeps
into the proper direction – either information about the -installed or the -default version.
Change History (9)
comment:1 Changed 3 years ago by ballapete (Peter "Pete" Dyballa)
comment:2 Changed 3 years ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
comment:3 Changed 3 years ago by mascguy (Christopher Nielsen)
Bear in mind that any deps based on path:
or bin:
may cause the results to not completely reflect reality, in terms of what is ultimately installed. That doesn't mean the list is incorrect, but rather, it's based on the default given by such deps.
So my guess is that such deps may be coming into play here.
comment:4 follow-up: 5 Changed 3 years ago by ballapete (Peter "Pete" Dyballa)
Therefore my wish to make it differentiate between ideal defaults and dirty reality.
comment:5 Changed 3 years ago by mascguy (Christopher Nielsen)
Cc: | jmroot ryandesign added |
---|
Replying to ballapete:
Therefore my wish to make it differentiate between ideal defaults and dirty reality.
I like the idea, at least in principle. But I'm not sure how feasible/realistic that is, given the dynamic nature of everything.
But I'll let @jmroot and @ryandesign speak to it.
comment:6 Changed 3 years ago by jmroot (Joshua Root)
Cc: | jmroot removed |
---|---|
Keywords: | Monterey removed |
Summary: | `port rdeps <whatever>` reports faulty dependencies → add a way to get rdeps of an installed version of a port |
Type: | request → enhancement |
Let's be honest in the summary; the reported deps are not inaccurate, they're just not for the version of the port that you happen to want at this moment.
comment:7 Changed 3 years ago by jmroot (Joshua Root)
Component: | ports → base |
---|---|
Port: | port removed |
comment:8 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign removed |
---|
comment:9 Changed 16 months ago by ernstki (Kevin Ernst)
Cc: | ernstki added |
---|
And it would make only sense, when
port rdeps
would use the whole dependency line down either this or that version. See for example this nonsense where not a singleport
is installed the usespython39
:Is
port
really able to install the properport
or upgrade properly the givenport
?