[arch-dev-public] Discussion about optional dependencies
Hi all, We need to have a discussion about optional dependencies. I am going to use virtualbox as an example, because of the 10 bugs and counting caused by people not seeing the change in dependency to run the gui. However, this is just the latest in the list of such issues. So lets look at the optional dependencies: Optional Deps : qt5-x11extras: GUI support vde2: Virtual Distributed Ethernet support virtualbox-guest-iso: Guest Additions CD image virtualbox-ext-vnc: VNC server support virtualbox-sdk: Developer kit net-tools: Host-only or bridged networking support The optional dependency of note here is "qt5-x11extras: GUI support"., which is needed to run /usr/bin/virtualbox. That is the primary "binary" of the virtualbox package. My opinion is the primary binary for a package should run out of the box. If you really need to reduce dependencies, then a split package should be considered. Comments/opinions? Thanks, Allan
I agree with this, and the same apply for vlc I think, which recently lost its qt4 dependency: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/vlc&id=b1a56bb8d107ebb51a6f2e32c67f866e2693517b -- György Balló Trusted User
On Tue, 2016-07-19 at 03:39 +0200, Balló György via arch-dev-public wrote:
I agree with this, and the same apply for vlc I think, which recently lost its qt4 dependency: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packag es/vlc&id=b1a56bb8d107ebb51a6f2e32c67f866e2693517b
-- György Balló Trusted User
For a case like that, it should really just be a split package. As long as there's still a main package named after the project for all the components, split packages aren't annoying. It's rarely worth putting in the effort to do that, but it's a much nicer way to do it than moving the problem to users.
In theory: +1 But splitting VLC properly is a non-trivial task. See FS#21934 if anybody wants to give it a shot (there are some issues not mentioned there, such as vlc crashing KDE applications if not all plugins are installed) Hopefully VLC 3 will make it easier. Daniel Micay via arch-dev-public wrote:
On Tue, 2016-07-19 at 03:39 +0200, Balló György via arch-dev-public wrote:
I agree with this, and the same apply for vlc I think, which recently lost its qt4 dependency: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packag es/vlc&id=b1a56bb8d107ebb51a6f2e32c67f866e2693517b
-- György Balló Trusted User
For a case like that, it should really just be a split package. As long as there's still a main package named after the project for all the components, split packages aren't annoying. It's rarely worth putting in the effort to do that, but it's a much nicer way to do it than moving the problem to users.
On 7/19/16, Antonio Rojas
In theory: +1
But splitting VLC properly is a non-trivial task.
I've had a very similar problem for several years with the Gnuradio package. It can either be run headless (which is usually how it is used in production) but it also has a graphical "flow language" IDE that is used during design. The IDE required around six optdeps. Some were required for the IDE to even start, some parts were optional-optional. Some were kind of confusing, since it could use either WX or QT. And like VLC, there was no upstream provision for actually splitting the headless and GUI parts. Gnuradio is about the same size project as VLC too. (The GUI optdeps would add about 600MB to a headless system. For "appliance" installs that run from an SD card, this is not a trivial waste.) The cleanest workaround was to make a fake kitchen sink package. It has no files but depends on all the optdeps. If I think the IDE needs a new depend, I add it to the kitchen sink and users get it automatically next update. If you want to make a streamlined install, you don't install the kitchen sink and just the optdeps you need. If the dangling packages are a bother for a nice clean dep tree, then it is easy (and doesn't require rebuilding anything) to make a custom fake pacakge to establish the dependency links. Pros get full control over the system by ignoring the fake package. Newbs get a zero maintainence just-works experience. I don't have to cut against upstream by trying to split the unsplitable. Pretty much everyone is happy and it has all but eliminated routine bugs/complaints/confusion. -Kyle
On 2016-07-20 20:36, keenerd via arch-dev-public wrote:
The cleanest workaround was to make a fake kitchen sink package. It has no files but depends on all the optdeps. If I think the IDE needs a new depend, I add it to the kitchen sink and users get it automatically next update. If you want to make a streamlined install, you don't install the kitchen sink and just the optdeps you need. If the dangling packages are a bother for a nice clean dep tree, then it is easy (and doesn't require rebuilding anything) to make a custom fake pacakge to establish the dependency links.
This is also how Sergej solved the issue with headless virt-install and graphical virt-manager. The virt-install package installs all files, but depends only on non-X packages, while virt-manager pulls missing dependencies. While confusing at first, I don't think there's a better solution for now. Bartłomiej
[2016-07-19 11:13:22 +1000] Allan McRae:
My opinion is the primary binary for a package should run out of the box. If you really need to reduce dependencies, then a split package should be considered.
That makes sense to me. -- Gaetan
On Jul 19, 2016 03:56, "Gaetan Bisson"
[2016-07-19 11:13:22 +1000] Allan McRae:
My opinion is the primary binary for a package should run out of the box. If you really need to reduce dependencies, then a split package should be considered.
That makes sense to me.
-- Gaetan
I also agree with that reasoning. Sven
My opinion is the primary binary for a
On mar., 2016-07-19 at 11:13 +1000, Allan McRae wrote: package should run out of the box. If you really need to reduce dependencies, then a split package should be considered. Comments/opinions? I think we provide a bad user experience when a program refuse to start because a shared library is missing. This sounds like a packaging issue and I agree we should improve the current situation. Keeping the proposed example, the binary which provides the primary functions of virtualbox (understand start/stop/edit VM) is vboxmanage. In fact "virtualbox" is the entry point to the Qt GUI. There is also an SDL GUI (VBoxSDL) and a no-GUI (VBoxHeadless). For a server usage (without screen) of virtualbox, the primary binary runs out the box without the Qt5 deps. Admin that Qt5 GUI is the primary binary/usage, what "run out of the box" means? Only display the GUI interface or the features behind ? When you create a VM (via this primary binary) with hostonly networking, it will not works until you install net-tools (currently a optdepds) and it's not obvious to figure out. So "primary binary" and "run out of the box" not really help to make the choice with no doubt. My current opinion is to only use optional dependencies to provides enhancement to the package which are not creating library dependency issues. Which means wherever the virtualbox binary is shiped, the deps to qt5 should be pulled with. Regards, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
participants (9)
-
Allan McRae
-
Antonio Rojas
-
Balló György
-
Bartłomiej Piotrowski
-
Daniel Micay
-
Gaetan Bisson
-
keenerd
-
Sven-Hendrik Haase
-
Sébastien Luttringer