Ticket #372 (closed defect: workaround)

Opened 12 years ago

Last modified 8 years ago

debathena-thirdparty prevents install of newer, conflicting package versions

Reported by: geofft Owned by:
Priority: normal Milestone: Current Semester
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

For instance, libboost-dev is version 1.34, and there's a libboost1.37-dev. They conflict, and attempting to install libboost1.37-dev offers to remove debathena-thirdparty-libraries, debathena-thirdparty, and debathena-cluster, which would then proceed to attempt to remove 1600 dependencies of debathena-cluster. This is highly unfortunate.

Probably all of thirdparty should be Recommendations...

(As a separate issue, do we want libboost1.37-dev instead of libboost-dev?)

Change History

comment:1 Changed 11 years ago by jdreed

  • Milestone set to Fall 2010

comment:2 Changed 11 years ago by geofft

What if we make thirdparty a task (as in tasksel) instead of a metapackage? That way we can install the task, but nothing happens to the package dependency system if you later want to uninstall something depended on by the task inside your login session.

(If other system / Debathena packages conflict with thirdparty, we lose anyway.)

comment:3 Changed 10 years ago by jdreed

  • Milestone changed from Natty Alpha to Fall 2011

comment:4 Changed 9 years ago by jdreed

I looked at tasksel. "Meh". It's basically used in order to pull in specific metapackages. We could create a thirdparty task that then installed debathena-thirdparty, but that doesn't really buy us anything, other than it being possible for a cluster machine to end up without thirdparty. I'd rather flip out and fix this with #1156.

comment:5 Changed 8 years ago by jdreed

OK, the easiest way to detail with this is to remove thirdparty as a dependency of cluster, and just install it manually in the installer. All the code is there (just unused), and getting a cluster machine without the installer is not a supported operation. However, we need to be clever about this so that it doesn't automatically uninstall everything and re-install it. I suspect the easiest ("easiest") way is to use the recovery hook to apt-mark debathena-thirdparty as manually installed.

comment:6 Changed 8 years ago by jdreed

OK, #1156 has been fixed, so we now just need to make the installer changes. This means that you will have to uninstall all of debathena-thirdparty if you want to use a different conflicting package version, but if you're doing that every single time, then a cluster machine is not what you want.

comment:7 Changed 8 years ago by jdreed

  • Status changed from new to review

comment:8 Changed 8 years ago by jdreed

So, do we want to do this? Or, do we want to make a point of paying closer attention to -thirdparty, and for things with multiple versions, make them recommendations of thirdparty, not dependencies? I think I favor the latter, actually.

comment:9 Changed 8 years ago by jdreed

  • Status changed from review to closed
  • Resolution set to workaround

So, nobody has any opinions on this, I'm going to call it done and not demote -thirdparty to a recommendation. Now that we're using apt-get universally, and autoremove is set to false (and we can continue to ensure it is, on cluster), "apt-get remove debathena-thirdparty" is a 30-second operation.

Note: See TracTickets for help on using tickets.