Deploy libstdc++.so.5 to the cluster machines

[jdreed]

Although we have done this on the dialups, we have not done it for cluster machines, and users have requested it. Can we simply turn on backports and hope for the best? What's the right way to do this? (And get the 32-bit version out there too?)

[jdreed]

I plan on deploying the following files. Feedback appreciated:

sources.list.d/debathena-backports.list

deb http://mirrors.mit.edu/ubuntu lucid-backports main restricted universe multiverse

/etc/apt/preferences.d/debathena-libstdcplusplus.pref

Package: *
Pin: release a=lucid-backports
Pin-Priority: -1

Package: libstdc++5
Pin: release a=lucid-backports
Pin-Priority: 500

[jdreed]

This is actually harder than we think, because any dependency on libstdc++5 can't be satisfied until c-l-c 1.31 is installed (and an apt-get update has been run, which the auto-updater will take care of).

At this point, I'm ok with telling people they'll need to explicitly install libstdc++5 at the beginning of their login session in order to use legacy apps.

[jdreed]

r25086

[jdreed]

And of course there's an upstream bug ( LP:508545) where aptitude ignores /etc/apt/preferences.d, and the fix was only just released for natty. So this harder. I don't think we want to do a straight transform of /etc/apt/preferences, because people may have changed that. I favor just appending to the file in the postinst. Thoughts?

[jdreed]

Er, we can just scribble over /etc/apt/preferences, because this is *cluster*-login-config. If you install c-l-c on not-cluster, you deserve what you get.

Fixed in r25095.

[jdreed]

Built and uploaded to -development.
... and I just violated the workflow policy.

[jdreed]

OK, the backports stuff for lucid made it into production (just in time for us to switch to Natty).

Natty is harder because we need to require both the 32 and 64-bit versions.

[jdreed]

OK, we still haven't added this to metapackages, and we need to. At this point, I'm going to back out the changes for lucid, because it's unclear when machines have backports already enabled and when they don't. I suggest we then change thirdparty (or thirdpart-libraries) into a non-equivs package, and depend on libstdc++5 on natty and higher.

How do we say "install both 32 and 64 bit versions on amd64, but onyl 32 on i386?" I assume we have to conditionalize on the arch type at build time, and determine whether to write "libstdc++5 [i386, amd64]" or "libstdc++5 [amd64]", right?

I'd love consensus on #963 before doing this.

[jdreed]

The actual dependency committed in r25280.

[jdreed]

After extensive zephyr discussion, we're going to revert the changes above and instead, in extra-software-nox, depend at build time on libcstdc++5 if it exists. extra-software-nox 1.2 is now in -dev, along with c-l-c 1.36.2.

Multiarch will be dealt with later, if there's a pressing need for it.