On 2019/07/08 20:46, Vadim Penzin wrote:
> 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).
I'm not aware of any breakage, I haven't tried recently but I would
expect lpr based printing to work just fine.
> 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, ...)
The file doesn't talk about gtk-cups (it might be sane to add a quick
reference to the gtk pkg-readme for that), but Firefox does have a
pkg-readme:
# pkg_add firefox
quirks-3.161 signed on 2019-07-06T11:04:28Z
firefox-67.0.4p0: ok
Running tags: ok
New and changed readme(s):
/usr/local/share/doc/pkg-readmes/firefox
> 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).
>
This does seem like quite a lot more complexity than would be the norm
for OpenBSD.
