When blivet becomes environment aware, it will not need to require these packages, since it should not fail in the event that these packages are not installed.
Presumably anaconda still wants the capabilities these packages provide, since it is used to having them through blivet, so add these Requires to anaconda.
Signed-off-by: mulhern amulhern@redhat.com
From: mulhern amulhern@redhat.com
When blivet becomes environment aware, it will not need to require these packages, since it should not fail in the event that these packages are not installed.
Presumably anaconda still wants the capabilities these packages provide, since it is used to having them through blivet, so add these Requires to anaconda.
Signed-off-by: mulhern amulhern@redhat.com --- anaconda.spec.in | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/anaconda.spec.in b/anaconda.spec.in index c1dd2d4..60866e3 100644 --- a/anaconda.spec.in +++ b/anaconda.spec.in @@ -42,6 +42,7 @@ Source0: %{name}-%{version}.tar.bz2 %define libxklavierver 5.4 %define libtimezonemapver 0.4.1-2 %define helpver 22.1-1 +%define libblockdevver 0.10
BuildRequires: audit-libs-devel BuildRequires: gettext >= %{gettextver} @@ -145,6 +146,10 @@ Requires: newt-python # required because of the rescue mode and VNC question Requires: anaconda-tui = %{version}-%{release}
+# Storage packages that blivet considers optional +Requires: libblockdev-plugins-all >= %{libblockdevver} +Requires: dosfstools + Obsoletes: anaconda-images <= 10 Provides: anaconda-images = %{version}-%{release} Obsoletes: anaconda-runtime < %{version}-%{release}
@@ -145,6 +146,10 @@ Requires: newt-python # required because of the rescue mode and VNC question Requires: anaconda-tui = %{version}-%{release}
+# Storage packages that blivet considers optional +Requires: libblockdev-plugins-all >= %{libblockdevver}
The idea behind this is that the ``libblockdev`` package will still be required by Blivet, right? I think we need some comment about it in the spec.
Generally, I'm not sure how to approach this from the right direction -- e.g. when I change something in blivet that requires new libblockdev with this I'll have to go to anaconda's spec and bump the required version of ``libblockdev`` there. That seems like a perfect thing to forget.
I know many guys don't like subpackages, but what about adding ``blivet-all` as a subpackage of Blivet pulling in blivet and all its external dependencies? That way we would keep track of Blivet's external dependencies in Blivet's spec where it really belongs and we will have an easy way of installing them all into the installation images.
I think the right way to do it is remove the version number and have anaconda depend on just the libblockdev-plugins-all package since it doesn't really care what the specific version is. blivet should enforce the specific version that it needs by a dependency on the main package, which I think will cause the correct plugin versions to be pulled in. No need for subpackages.
I think the right way to do it is remove the version number and have anaconda depend on just the libblockdev-plugins-all package since it doesn't really care what the specific version is. blivet should enforce the specific version that it needs by a dependency on the main package, which I think will cause the correct plugin versions to be pulled in. No need for subpackages.
How should that happen? The ``libblockdev`` (main) package doesn't require the plugins and thus cannot require any specific version(s).
Will the versions of the plugins and the version of libblockdev proper always be so tightly coupled as they are now? If not, then this problem will soon look a bit different and updating the plugin version(s) separately from the library will seem exactly right.
Will the versions of the plugins and the version of libblockdev proper always be so tightly coupled as they are now? If not, then this problem will soon look a bit different and updating the plugin version(s) separately from the library will seem exactly right.
One of the key ideas behind the complicated design of a library with a lot of plugins is that it allows for better granularity of updates so the above is an exactly valid concern. Once it stabilizes a bit the ``libblockdev`` package (the library) should be stable and unchanged unless new plugins are added.
How should that happen? The libblockdev (main) package doesn't require the plugins and thus cannot require any specific version(s).
I think (not having tried this) that by blivet requiring a newer libblockdev the plugins will be updated to the latest available version.
anaconda-patches@lists.fedorahosted.org
-
dashea