On 2019/07/08 23:42, Vadim Penzin wrote: > On 7/8/19 10:23 PM, Stuart Henderson wrote: > > 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. > > That was exactly my point: in the `basic' setup (perfectly printing CUPS but > no gtk+[23]-cups installed) Firefox offers nothing but saving a page as PDF.
Well that is unexpected to me. With gtk+2 Firefox definitely offered lpr as an option. I'm not sure if I have tried Firefox without gtk-cups after the switch to Gtk+3 to know if that's just a difference with Gtk+3, or if it used to work how I expect and has since changed. > The same goes for Thunderbird, Gimp, and maybe others. Thunderbird I would expect to behave the same as Firefox. I have just tested Gimp after uninstalling gtk+2-cups and that does work how I'd expect: allows saving to a file or using lpr. > > > 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 > > > > Right, I was not precise: I meant to say that there is nothing relevant to > printing in this file, there is no separate README dedicated to printing, > and there is no specific message (similar to what Python displays about > symlinking to the default interpreter). At very least, /this/ should not be > that way, I think. > > > > 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. > > > > > This does seem like quite a lot more complexity than would be the norm > > for OpenBSD. > > It is not impossible to add pre/post event hooks to pkg_add(1) and > pkg_delete(1), such a mechanism could be self-contained: all it is supposed > to do is to analyse /var/db/pkg and give the user a good advice in the form > of text. Execution of hooks should be optional: users that know their stuff > by heart do not really need it. Sure, such a mechanism implies making > extensions to packing lists. > > Consider PDF viewers or terminal emulators that could be reconfigured or > replaced with packages of a different flavour if a Web browser becomes > available and following hyperlinks is possible. I suppose the key part of this would be the database of information. That could be started with something that reads pkg_info output and gives advice, someone interested in such a thing could throw together a proof of concept pretty quickly as a simple shell script. Though to be honest I don't really see there being many packages where such information would apply, only two or three come to mind where there are optional dependencies, which is why we haven't gone further than short notes in readmes. > Just an idea. It is more time we are short on rather than ideas ;)
