Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refine versioned dependencies on -bridge/-shell subpackages #5997

Closed
martinpitt opened this issue Mar 1, 2017 · 1 comment
Closed

Refine versioned dependencies on -bridge/-shell subpackages #5997

martinpitt opened this issue Mar 1, 2017 · 1 comment

Comments

@martinpitt
Copy link
Member

Right now we have a rather coarse-grained way to compute dependencies for RPM:

%define required_base <value of tools/min-base-version>

%package machines
Summary: Cockpit user interface for virtual machines
Requires: %{name}-bridge >= %{required_base}
Requires: %{name}-system >= %{required_base}

similarly for the other module packages.

tools/min-base-version gives the maximum of all the "requires cockpit" versions of all subpackages, so that's unnecessarily strong. E. g. if we bump dashboard's cockpit dependency to use a new D-Bus API, the -machines package doesn't need to bump its dependency also.

The difficulty (and reason why we only have the above right now) is that rpm spec files don't allow you to call a program to compute the value of a Requires: -- if we had that, we could just refine min-base-version to give it a set of pkg/* modules (from the %files list) and use that instead of a global %required_base.

So we need to do that externally, like we currently set %required_base:

Makefile.am:    [ ! -e $(distdir)/tools/cockpit.spec ] || sed -ri "s/^(.*%define required_base).*$$/\1 $$($(srcdir)/tools/min-base-version)/" $(distdir)/tools/cockpit.spec

We could use the same approach (modify the .spec file during make dist) for the individual subpackages of course, but we don't have access to the value of %files at that point. So we won't be able to avoid all redundancies. But most of our binary packages that act as "plugins" (like -networkmanager or -pcp) only ship one pkg/* module, and for a base package like -system which ships multiple it might actually be acceptable to just use the "maximum dependency to -bridge" from above, as it's rather unlikely that you would decouple -bridge and -system in a distribution.

@martinpitt
Copy link
Member Author

martinpitt commented Mar 1, 2017

I reviewed our usage of %required_base in cockpit.spec, and indeed we only use it on binary packages which are "extensions" such as -pcp or -networkmanager -- all of these ship only one pkg/*. Our "core" packages -dashboard, -system, and -ws don't use it and they already have manually maintained dependencies, and -dashboard always has a strict "same upstream version" dependency to -bridge already.

This makes this much easier: in make dist we could just iterate over all %packages $p and replace %required_base with the value from pkg/$p/manifest.json's requires[cockpit]. This avoids having to interpret/guess at the %files list from outside, doesn't duplicate dependency information from anywhere, and is reasonably easy to implement.

martinpitt added a commit to martinpitt/cockpit that referenced this issue Mar 1, 2017
We don't want every binary RPM package to depend on the global maximum
of requires["cockpit"] of all our pkg/*, as this is too strict for e. g.
RHEL. Instead, for a plugin package cockpit-foo we only want the
required version from pkg/foo/manifest.json.in.

Add tools/gen-spec-dependencies which iterates over a spec file and
replaces %{required_base} with the correct dependency (via
min-base-version <pkg>), and call that during "make dist" so that the
distributed spec file is correct.

This introduces the assumption that we use %{required_base} *only* for
binary packages which actually correspond to a pkg/* module. For our
base packages (-ws, -system) we still need to specify the dependencies
manually, which is fine as we can't represent them in our pkg/*
manifests anyway.

Fixes cockpit-project#5997
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant