Please backport mpich2/1.3.1-1 from natty

Reported by Lucas Nussbaum on 2010-12-12
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Lucid Backports
Undecided
Unassigned
maverick-backports
Won't Fix
Undecided
Unassigned

Bug Description

this is an easy no-change backport.

Evan Broder (broder) wrote :

I've opened a task for maverick-backports so that we can ensure a smooth upgrade path from Lucid through to Natty. I've also uploaded test builds for Lucid and Maverick to my PPA (https://launchpad.net/~broder/+archive/backports-tests); the test builds should be available shortly.

For each binary package for both Lucid and Maverick, we need confirmation that the package builds, installs, and runs (where there is something to run).

mpich2 has a few reverse dependencies: gromacs-dev and gromacs-mpich in both Lucid and Maverick, additionally yorick-mpy-mpich2 in Maverick.

For rdeps, we need confirmation that the packages in the main archive still work with the backported packages without requiring a rebuild. Please confirm that the 3 packages above work in both Lucid (where applicable) and Maverick with the backported packages.

The package also has reverse build dependencies: gromacs in both Lucid and Maverick, additionally yorick in Maverick

For r-build-deps, we need confirmation that the version of the package currently in the archive still builds against the backported package. I'll submit no-change rebuilds of gromacs and yorick to my PPA once mpich2 has finished building.

The most direct way to move this backport forward would be for you to check that the packages b/i/r and that the rdeps still work.

On 13/12/10 at 10:32 -0000, Evan Broder wrote:
> I've opened a task for maverick-backports so that we can ensure a smooth
> upgrade path from Lucid through to Natty. I've also uploaded test builds
> for Lucid and Maverick to my PPA (https://launchpad.net/~broder/+archive
> /backports-tests); the test builds should be available shortly.
>
> For each binary package for both Lucid and Maverick, we need
> confirmation that the package builds, installs, and runs (where there is
> something to run).
>
> mpich2 has a few reverse dependencies: gromacs-dev and gromacs-mpich in
> both Lucid and Maverick, additionally yorick-mpy-mpich2 in Maverick.
>
> For rdeps, we need confirmation that the packages in the main archive
> still work with the backported packages without requiring a rebuild.
> Please confirm that the 3 packages above work in both Lucid (where
> applicable) and Maverick with the backported packages.
>
> The package also has reverse build dependencies: gromacs in both Lucid
> and Maverick, additionally yorick in Maverick
>
> For r-build-deps, we need confirmation that the version of the package
> currently in the archive still builds against the backported package.
> I'll submit no-change rebuilds of gromacs and yorick to my PPA once
> mpich2 has finished building.
>
> The most direct way to move this backport forward would be for you to
> check that the packages b/i/r and that the rdeps still work.

The r-deps and r-b-deps won't work due to the SONAME bump. Though I
don't think that it's a problem to break reverse-dependencies since we
are talking about uploading mpich2 to -backports, not to -updates.
If users want to keep using gromacs and yorick with mpich2, they can
stay with the package in the standard archive.

Lucas

Evan Broder (broder) wrote :

Ah, sorry - I missed the SONAME bump since the new version hasn't actually been published yet. In general, we do monitor both r-deps and r-b-deps as part of the backports testing process - see the discussion at https://help.ubuntu.com/community/UbuntuBackports

In this particular case, you're right that the r-deps won't be affected by the SONAME bump. However, the r-b-deps are still relevant, since the packages b-dep on libmpich2-dev, which does not contain the SONAME. If they were rebuilt with the backport installed, they would build against the backport, so we need to make sure that still works.

Lucas Nussbaum (lucas) wrote :

On 13/12/10 at 11:08 -0000, Evan Broder wrote:
> Ah, sorry - I missed the SONAME bump since the new version hasn't
> actually been published yet. In general, we do monitor both r-deps and
> r-b-deps as part of the backports testing process - see the discussion
> at https://help.ubuntu.com/community/UbuntuBackports
>
> In this particular case, you're right that the r-deps won't be affected
> by the SONAME bump. However, the r-b-deps are still relevant, since the
> packages b-dep on libmpich2-dev, which does not contain the SONAME. If
> they were rebuilt with the backport installed, they would build against
> the backport, so we need to make sure that still works.

Why would they be rebuilt with the backport installed?
This wouldn't happen in LP chroots (or at least I hope so).

- Lucas

Scott Kitterman (kitterman) wrote :

Due to the soname change, as long as both versions of the library are co-installable, I think this is OK (since packages from the release pocket will still run with the release version).

Evan Broder (broder) wrote :

I'm closing the maverick-backports task on this bug due to Ubuntu 10.10 (Maverick Meerkat) no longer being supported.

This bug is being closed by a bot. If you feel the change was made in error, please feel free to re-open the bug. However, backports requests for Ubuntu 10.10 (Maverick Meerkat) are no longer being accepted.

Changed in maverick-backports:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers