qubes-core-agent-networking deb dependency issue

[a-barinov]

Qubes OS version:

R4.0

Affected component(s):

qubes-core-agent-networking debian package

---

Steps to reproduce the behavior:

Install 'qubes-core-agent-networking' in a debian template to be used by netvm.

Expected behavior:

'qubes-core-agent-networking' should recommend 'iproute2' so that it gets installed ( or at least can be discovered) by installing 'qubes-core-agent-networking'. It would also be beneficial to put explanation of 'iproute2' dependency requirement in package description as this is only needed for netvms.

Actual behavior:

'iproute2' that is required for netvm to route traffic properly is not installed. Furthermore 'iproute2' in not listed in any dependencies (depends, recommends, suggests) of 'qubes-core-agent-networking' package.

General notes:

---

Related issues:

[unman]

@a-barinov How did you get to a template without iproute2? It is installed in the default template. It's also installed in the minimal Debian template.
The reason is that it will be included in any Debian template because it's included in the base system, because it has priority important.
As far as I can see you would have to configure your template to remove the package before hitting this problem.
I dont think it's necessary to cite packages in the base system in "recommends".

[a-barinov]

@unman You are right, according to Debian manual "Important packages should be found on any Unix-like system". Nevertheless there is nothing in Debian Policy that would warrant not declaring a dependency on a package on the grounds that the required package has priority of 'important' - so this is definitely a bug, whether the target package is in the default installation list or not. BTW, the way Debian Policy describes 'Recommends' relationship fits iproute2 relation perfectly: "The Recommends field should list packages that would be found together with this one in all but unusual installations"

There is a good reason for mandating explicit declaration of dependencies: Debian own tools do not care about 'important' priority in practice. The only priority of Debian package that would not allow automatic uninstall when there are no dependencies to keep it in the system is 'required'. So the following bits in apt config will get you iproute2 uninstalled under some circumstances:
APT::Force-LoopBreak "true";
APT::Install-Recommends "false";
APT::AutoRemove::RecommendsImportant "false";
APT::AutoRemove::SuggestsImportant "false";

My case for uninstalling iproute2 is very simple: I'm starting every Debian install with marking all the packages as automatically installed, then marking a few packages I need as manual and letting apt to uninstall all the useless stuff. In case of Qubes OS (which is not too different from AWS headless installs) the minimal set of packages to get the system running is:

• qubes-vm-dependencies
• qubes-core-agent-networking
• kmod
• mc (or another editor)
• whiptail (or another debconf frontend)
• sakura (or another terminal emulator)
• aptitude (optional, can use apt-get instead)
• localepurge (optional but saves lots of space)
  With this fully functional setup where every package has a valid reason to be installed how do you expect me to know why the vm will fail as netvm? Debian Policy is explicit about this and provides package dependencies as the solution.

[Nurmagoz]

It's also installed in the minimal Debian template.

@unman We have minimal debian template and its not documented?

[marmarek]

'qubes-core-agent-networking' should recommend 'iproute2'

If package functionality is broken by lack of iproute2, then it should depend, not only recommend.

[a-barinov]

It is broken only in case you use the vm as netvm, otherwise things work just fine. Therefore 'recommends' looks more appropriate to me than 'depends'.

[marmarek]

How user is going to find that it's iproute2 specifically required for netvm functionality? If we'd have separate packages for "basic networking" and "providing network for others", then yes, iproute2 could be added to just one of them. But in the current package layout qubes-core-agent-networking is broken if one use --no-install-recommends (and remove iproute2 before).

[unman]

In the current situation, it should be included as a Dependency.
It's a moot point whether we should replace the current dependency on net-tools with iproute2.

@a-barinov I wasn't querying whether it should be referenced, but how you got to the state of not having it installed.
The key here is:

and letting apt to uninstall all the useless stuff

As you've discovered, if you want a Debian install that works well when networked (whether it's a router or not), it isn't a good idea to remove core networking tools. You can do this, of course, but "the system will not run well or be usable without them". (That's why they are important.)

And the answer to the question, how do you know iproute2 is required, isn't "because it's a dependency of some other package" but "because you need tools that allow you to control networking".

Have you considered building the template using debootstrap with the minbase option?

@TNTBOMBOM

We have minimal debian template and its not documented?

The page on Templates makes it clear that there are flavours available only in source code. debian+minimal flavours are included as an option in qubes-builder, and have been regularly referenced on the mailing lists.
I've occasionally provided a pre-built minimal template myself: I'll put one up later tonight.

[a-barinov]

A fair point. There are 3 options that I see to solve this: 1. Create a new 'qubes-core-agent-networking-netvm' package that will be intended for netvms and will depend on ''qubes-core-agent-networking' and 'iproute2'. 2. Add 'iproute2' as recommended to 'qubes-core-agent-networking' dependencies, mention in package description that iproute is required for netvm functionality to work. 3. Add 'iproute2' to the list of dependencies (I mean 'Depends' type dependency) of 'qubes-core-agent-networking'. Of all these options (3) is easiest to implement and also leaves no room for user mistakes - so looks like the solution you proposed is the best. On 10/22/18 02:07, Marek Marczykowski-Górecki wrote: How user is going to find that it's iproute2 specifically required for netvm functionality? If we'd have separate packages for "basic networking" and "providing network for others", then yes, iproute2 could be added to just one of them. But in the current package layout qubes-core-agent-networking is broken if one use --no-install-recommends (and remove iproute2 before). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. {"api_vers

[Nurmagoz]

The page on Templates makes it clear that there are flavours available only in source code. debian+minimal flavours are included as an option in qubes-builder, and have been regularly referenced on the mailing lists.
I've occasionally provided a pre-built minimal template myself: I'll put one up later tonight.

i mean something like this:

sudo qubes-dom0-update qubes-template-debian-9-minimal

[marmarek]

On Mon, Oct 22, 2018 at 07:47:15AM -0700, unman wrote: > We have minimal debian template and its not documented? The page on [Templates](https://www.qubes-os.org/doc/templates/) makes it clear that there are flavours available only in source code. debian+minimal flavours are included as an option in qubes-builder, and have been regularly referenced on the mailing lists. I've occasionally provided a pre-built minimal template myself: I'll put one up later tonight.

Since we have automated scripts for building templates now, we can also include minimal template in official repositories too. I can also grant you the power for triggering the build yourself @unman. See #3935 (comment)

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[andrewdavidwong]

I've branched the debian-minimal issue to #4422.