Jun 4, 2020, 15:39 by m...@ambrevar.xyz:
> It's not very obvious what to document it since it applies to all > WebKitGTK. > One idea is to indicate the relationship between packages. For example, guix package -s gstreamer | less ... + Applications can take advantage of advances in codec and filter technology + transparently. Developers can add new codecs and filters by writing a simple + plugin with a clean, generic interface. + + This package provides the core library and elements. <new>See gst-plugins-* for additional codecs, filters, and functionality.</new> Another is to describe an end-user's perspective of the gst-plugins-*. The description taken from GStreamer focuses on licensing and is developer-centric. It's unclear as a user that the plugins may solve my problem. Maybe something like, guix package -s gst-plugins-ugly | less ... + description: GStreamer Ugly Plug-ins <new>for extra codecs, filters, and functionality</new>. This set contains those plug-ins which + the developers consider to have good quality code but that might pose + distribution problems in some jurisdictions, e.g. due to patent threats. > It's part of the "general software knowledge". For instance, if you > install an archiver like `atool', it's your reponsibility to install the > backends (unzip, p7zip, etc.) to support the various archive formats. > Where to document this? I don't know, but it's unclear that Guix is the > place. > I follow you. Some tools, like `atool`, make that responsibility clear in their documentation. Unfortunately, GStreamer is not as clear. That's an upstream issue. Guix could help users by providing a recipe or a ready-to-use package. Is the Guix Cookbook not an appropriate place for a tutorial on setting up a Guix System for general web viewing? This seems within Guix's purview. I couldn't find a webviewer through Guix which allowed me to view the Guix videos out-of-the-box. I'm happy to help with any of these.
