On 7/8/19 5:58 PM, Stuart Henderson wrote:
On 2019/07/08 12:24, Vadim Penzin wrote:
On 7/8/19 12:04 PM, Antoine Jacoutot wrote:
On Mon, Jul 08, 2019 at 11:35:29AM +0300, Vadim Penzin wrote:
This is exactly how I solved the problem. About an hour lost in wondering
what can be wrong with otherwise perfectly functioning setup.
Do you (I liked that royal `we'!) expect the user to read READMEs of every
package that Firefox et al. depend on directly or indirectly?
No but if you want to print using cups, I expect you to read at least the cups
README:
I have done my bit by telling the package manager that I want Firefox *and*
CUPS. It should have worked.
pkg_add doesn't have heuristics to install an optional dependency
just because you installed two other packages. Mind you, I'm not aware
of a package manager on another OS that does that either, they usually
just force the dependency.
OpenBSD can be very much better at a very low expense: every package
that is known (by the maintainer) to be broken unless the user takes an
action should include relevant documentation (if simply forcing a
dependency is as expensive as you described).
In my case, several months passed since I installed CUPS and before I
installed Firefox. Firefox comes without READMEs and pkg_add(1) issues
no messages about things to take care of to make it run (I use OpenBSD
since about 2.x series, I am aware of package-specific documentation and
I do pay attention). Naturally, I supposed that I am good to go.
The above could have been avoided if pkg_add(1) were not silent while
installing Firefox (and Thunderbird, and Gimp, ...)
Now to the fantasy world.
I am not aware of the heuristics that you described either, but it does
not mean that a helpful hinting mechanism can not be designed and developed.
For instance, imagine that there is a list of known capabilities:
`printing', 'media playback', `Web browsing', etc. Two (or more, related
or not, conflicting or not) sub-trees of dependent packages may provide
a certain capability.
When the user installs, say, CUPS, the machine is marked as having the
`printing' capability. Later, when the user installs, say, Firefox
(that is known to be broken in the absence of gtk+[23]-cups IFF the user
requires printing) the package manager could make note that this machine
has the printing capability and---at very least---issue a warning that
reminds the user that there is an additional step to perform if the user
intends to use that capability with Firefox.
Vice versa, if CUPS is installed after Firefox, pkg_add(1) could issue a
message that a whole new capability just became available and there are
installed packages that can benefit from it if the user takes certain
actions (reading a relevant README, for instance).
Such a mechanism could be quite smart if it is aware of available
flavours of packages (and, maybe, ports).
