Reduce package/library duplication in lucid
Lucid has a lot of duplicated library and package versions. For improving supportability, reducing CD sizes/memory overhead, and avoiding library conflicts we should clean those up and build packages against the latest available versions.
- Robbie Williamson
- Martin Pitt
- Series goal:
- Accepted for lucid
- Milestone target:
- Started by
- Martin Pitt on 2010-03-08
- Completed by
- Martin Pitt on 2010-04-01
[pitti] investigate/drop gmime2.2: DONE
[mvo] check whether python-gtkhtml2 can sensibly be dropped from apturl (move to python-webkit?), and drop it if appropriate: DONE
[pitti] stop building python-gtkhtml2 from gnome-python-
[pitti] stop building python-
[pitti] remove polkit-qt and policykit: DONE
[pitti] migrate readline5 rdepends to readline6: DONE
Work items (ubuntu-
[doko] db4.7: migrate python2.6: DONE
[pitti] db4.7: migrate drac: DONE
[pitti] db4.7: migrate cyrus-sasl2: DONE
[pitti] db4.7: migratelibberke
[pitti] db4.7: migrate sendmail: POSTPONED
db4.7: migrate openldap: DROPPED
investigate/drop tcl8.4/tk8.4: DROPPED
Work items for Java-related libraries, being pulled in through eucalyptus:
[ttx] investigate/drop asm and asm2 in favor of asm3 (can't drop): DONE
[ttx] Move libservlet2.
[ttx] investigate building dom4j with only one libxpp version (3) (can't drop): DONE
Work items (targets of opportunity, low priority):
[doko] check if gcc/gcj builds with autoconf2.60 and drop autoconf2.59: DROPPED
[pitti] fix rdepends of automake1.7 and demote: DONE
pitti, 2010-03-08: I checked lucid main for duplicate versions and added them to the wiki page. There is certainly some stuff that we can ignore (like multiple build-time tools versions, especially if they would only lead to introducing a delta to Debian), but some libraries seem quite important. Initial proposed set of work items created.
Open question is whether we want to attempt to get rid of tcl/tk 8.4?
LSB 4.0 (the one that we currently use) requires Qt3 (as well as Qt4), so we can't drop that yet.
libgdata and the libgdata1.2 from evolution are two totally different APIs, so nothing to migrate there.
- python2.6 & db4.8: backported and tested, upload after beta1
- db4.7: major blocker is python2.6; besides changing the configure check, this needs checking for regressions when
+building with db4.8
- autoconf2.59/gcc: WONTFIX; this package was explicitly introduced for gcc-4.4, and either would require pregenerating all configure file with 2.60, or updating gcc-4.4 to use a newer autoconf which is a major pain.
Would deprecation of libglade in favor of gtkbuilder fit into this spec?
I haven't done any rdepends, but I suspect there is a lot of code still using libglade, even though it is being deprecated (http://
pitti, 2010-03-10: This doesn't cover things like glade vs. GtkBuilder, since these are two different APIs (they are just duplicates in a "purpose" sense). This particular topic was discussed in a different blueprint: https:/
pitti, 2010-03-30: Migrated most stuff to db4.8. I tried sendmail, but it uses on-disk transactions and needs proper migration code in postinst. Since the sendmail binaries are in universe, and this will require a nontrivial amount of work and testing, I drop this for lucid. Remaining one is openldap.
ziesemer, 2010-04-30: Why was openldap dropped for db4.8? Anything I can help with? (I'd like to have this for my own system, without having to re-patch everytime there is an update.) Edit: Created bug: https:/