Bug#510845: mpi-defaults: FTBFS/not available on alpha

[Adeodato Simó]

* Manuel Prinz [Sat, 14 Mar 2009 22:31:45 +0100]:

> Hi Adeodato!

Hello!

> Am Freitag, den 13.03.2009, 21:41 +0100 schrieb Adeodato Simó:
> > > Open MPI used to build fine on alpha, so this is probably a problem with
> > > the new upstream release. Reassigning to Open MPI maintainers.

> > It’s been 2 months, and this issue has not been addressed. In the
> > meantime, I’m starting to smell packages build-depending on mpi-default-dev
> > that will prevent transitions from happening.

> Yes, I know about that. As a result of the recent breakage, Dirk left
> the team since he does a lot of stuff in Debian already, so the "team"
> is actually me. I had not much time lately but took this weekend of and
> am working on the problems this very moment. I'm sorry that it took so
> long.

Okay, no worries. We all get busy, it’s just appropriate that the task
gets done at some point. :-)

> > You were right in reassigning, since openmpi should have a bug of its
> > own for this failure. However, mpi-defaults is buggy as well, because
> > it’s failing to provide packages for alpha.

> > I also see #517543 now. IMO, either that patch is correct and can be
> > applied soon, or mpi-defaults needs to start thinking about using an
> > alternative implementation on alpha. Thoughts?

> I'm trying the patch but it does not fix the issue completely, as it
> seems. I hope I can give an update in a few hours. Once this is fixed,
> the build issue on Sparc can be probably fixed in a similar way. But I
> have to investigate that on a porter machine since I do not own this
> arch. (Well, same for alpha, but DSA kindly installed everything needed
> on albeniz.)

Good, thanks!

> As you may have noticed, I uploaded a fixed mpi-defaults earlier. I
> discussed the alpha issue with Adam and we agreed on falling back to LAM
> here. I did not know that sparc also fails then, so the "fix" will not
> work; but because of sparc this time.

I hadn’t noticed, thanks for telling me. There is an unfortunate problem
with it, though: you can’t use an architecture restriction like [arch1
!arch2] in Build-Depends. That is, you can’t mix ! and non-!; if you
stop to think about it, it doesn’t make sense.

Just removing “alpha” completely from the Build-Depends line will just
do the right thing as far as I can see. Could you make another upload?

> As for Open MPI, there are more than just build issues. I will fix these
> first, but there is also the problem of an ABI change. The upload was
> done a little hasty and the change not recognized, so the
> build-depending packages are effected. Most of them (if not all) will
> still run, but with a warning. The obviously needs to be fixed. Dirk
> came up with the idea of binNMUing but that that was not very welcomed
> by the maintainers of build-depending packages. I do not know what the
> right approach is. Upstream is now aware of that and will be ABI
> compatible starting from 1.3.2. I wanted to change the library package
> name and maybe bump the SONAME, and upload that package to experimantal.
> Of course, I wanted to mail the release team to coordinate that, but I
> wanted to fix one issue at a time. I have not made my mind up what is
> the best solution yet; just recompiling dependant packages would do the
> trick; users of Open MPI are used to recompile their software anyway,
> since upstream clearly stated that they never cared about ABI changes
> between releases. Any input is welcome. But I'll first try to get the
> package build again, collecting the broken pieces is second on my list.

Hm. Well, a warning is one thing, and the applications not working is
another. libopenmpi1 is in lenny, with packages depending on it. Partial
upgrades ought to work, so if applications stop working, seems like a
SONAME bump is in order. If it’s only a warning, it can be fixed with
Bin-NMUs, but it should be assessed with care.

I guess that when you say, “Upstream [...] will be ABI compatible
starting from 1.3.2”, you mean that they don’t intend to bump the SONAME
themselves for the breakage introduced earlier? That’d be a good start
if you want to show you care about ABI compatibility...

Finally, what’s this business about maintainers not being happy about
Bin-NMUs of their packages?

> Thanks for caring! And sorry for the f***-up!

As said above, no worries.

Thanks for your work,

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai