I'm looking to remove the -mpi subpackage of paraview because it does not build. I've poked upstream to no avail, and I haven't been able to figure out the problem myself. If this gets fixed, I'd like to add it back.
In the meantime, what kind of Provides/Obsoletes makes sense?
Provides: paraview-mpi Obsoletes: paraview-mpi < %{version}-%{release}
?
Orion Poplawski wrote:
I'm looking to remove the -mpi subpackage of paraview because it does not build. I've poked upstream to no avail, and I haven't been able to figure out the problem myself. If this gets fixed, I'd like to add it back.
In the meantime, what kind of Provides/Obsoletes makes sense?
Provides: paraview-mpi Obsoletes: paraview-mpi < %{version}-%{release}
imo, if the mpi functionality is missing, you should omit the Provides.
-- Rex
Orion Poplawski wrote:
I'm looking to remove the -mpi subpackage of paraview because it does not build. I've poked upstream to no avail, and I haven't been able to figure out the problem myself. If this gets fixed, I'd like to add it back.
In the meantime, what kind of Provides/Obsoletes makes sense?
Provides: paraview-mpi Obsoletes: paraview-mpi < %{version}-%{release}
If the functionality of the -mpi subpackage is not going to be provided at all (temporarily or otherwise), then neither.
Use an rpm macro to include/exclude the package:
%define with_mpi 0
Then wrap all areas of the spec file that concern the generation of mpi functionality, installation, packaging, file manifest, etc. with "%if %{with_mpi}" or "%if ! %{with_mpi}" checks as appropriate.
Having package contain Provides/Obsoletes for a previous subpackage which provides some actual functionality, but which is not present due to being disabled, means that software which requires the functionality is lied to, and dependency resolution is tricked into working, but there are runtime software failures or similar.
Not the correct way to go.
Mike A. Harris wrote:
If the functionality of the -mpi subpackage is not going to be provided at all (temporarily or otherwise), then neither.
Use an rpm macro to include/exclude the package:
%define with_mpi 0
Then wrap all areas of the spec file that concern the generation of mpi functionality, installation, packaging, file manifest, etc. with "%if %{with_mpi}" or "%if ! %{with_mpi}" checks as appropriate.
Did that already, thanks.
Having package contain Provides/Obsoletes for a previous subpackage which provides some actual functionality, but which is not present due to being disabled, means that software which requires the functionality is lied to, and dependency resolution is tricked into working, but there are runtime software failures or similar.
Not the correct way to go.
Okay. Is there any concern about old paraview-mpi packages being stranded, in case this can't be fixed by F7 release (or freeze)?
Orion Poplawski wrote:
Mike A. Harris wrote:
Having package contain Provides/Obsoletes for a previous subpackage which provides some actual functionality, but which is not present due to being disabled, means that software which requires the functionality is lied to, and dependency resolution is tricked into working, but there are runtime software failures or similar.
It's only a lie if a false Provides is added, imo.
Okay. Is there any concern about old paraview-mpi packages being stranded, in case this can't be fixed by F7 release (or freeze)?
Yes, a problem, which is why I recommended using Obsoletes, but not Provides. Without out, users with it currently installed may/will soon end up with dependency problems.
-- Rex
packaging@lists.fedoraproject.org