Branches for Wily

Author: Ron Lee
Revision Date: 2015-08-06 00:20:48 UTC

* Conflict/Replace libvpb0. Closes: #794587
* This is really just a kludge-around for the fact that we have unversioned
  files installed in the runtime library package, which ordinarily would be
  a Terribly Wrong thing to do, but this code is stable and had a strong
  guarantee that the ABI was never going to be broken and it would never
  need a transition, so for several reasons that was the least worst option
  for nearly 10 years now. Until gcc-5 broke that promise on us ...
  In this case, we can probably still quite reasonably get away with just
  forcing the old package off the system when it is upgraded, since there is
  a fairly natural limit to how many applications you can have controlling
  your phone lines on a system, and no real user is likely to actually need
  the old and new packages to be co-installable. Either they'll update to
  the new one, or they won't. There's no prolonged transition where things
  they might need could still be using the old one. It's still technically
  wrong though, so kids don't try this at home, but unless gcc starts to
  make a habit of this, it's probably the least disruptive change we can
  impose on users to cope with that transition, and hopefully something we
  won't need to deal with again for at least another ten years. If we do,
  then we'll reassess where the pros and cons really lay for making more
  intrusive changes to support things that "should have never happened".

Author: Ron Lee
Revision Date: 2015-08-06 00:20:48 UTC

* Conflict/Replace libvpb0. Closes: #794587
* This is really just a kludge-around for the fact that we have unversioned
  files installed in the runtime library package, which ordinarily would be
  a Terribly Wrong thing to do, but this code is stable and had a strong
  guarantee that the ABI was never going to be broken and it would never
  need a transition, so for several reasons that was the least worst option
  for nearly 10 years now. Until gcc-5 broke that promise on us ...
  In this case, we can probably still quite reasonably get away with just
  forcing the old package off the system when it is upgraded, since there is
  a fairly natural limit to how many applications you can have controlling
  your phone lines on a system, and no real user is likely to actually need
  the old and new packages to be co-installable. Either they'll update to
  the new one, or they won't. There's no prolonged transition where things
  they might need could still be using the old one. It's still technically
  wrong though, so kids don't try this at home, but unless gcc starts to
  make a habit of this, it's probably the least disruptive change we can
  impose on users to cope with that transition, and hopefully something we
  won't need to deal with again for at least another ten years. If we do,
  then we'll reassess where the pros and cons really lay for making more
  intrusive changes to support things that "should have never happened".