Description of problem: Trying to build a package for mysql-administrator it has a dependency on gtkmm20 i realised there is no gtkmm20 in FC4 its available in FC3 and development but not FC4 can you please request a build Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. try to build package for FC4 using gtkmm20 2. 3. Actual results: nuild fails cant find gtkmm20 Expected results: build finds gtkmm20 and succeds Additional info:
I specifically requested that the gtkmm20 suites of libraries be dropped for FC4 and onwards, since they're obsolete and no longer maintained. To my knowledge all major gtkmm-based apps had then moved on to the 24 API, but i didn't know about mysql-administrator. I would recommend that instead of reviving the gtkmm20 RPMs, we actually port mysql-administratot to gtkmm24. I've done 20-to-24 ports before and it's usually pretty straightforward, so if you want i can take a crack at it.
Seems they've come back during the April 11th and May 22th mass-rebuilds, since they had not been deleted/disabled in devel CVS: gconfmm20, gtkmm20 (April 11th) libglademm20, libgnomecanvasmm20, libgnomemm20, libgnomeuimm20 (May 26th) Can you please disable %prep (with a warning and exit 1) or delete them in devel CVS? Then I will make sure the rpms are removed, too.
Well the mysql suite of utilities specifically require them (there is mysql-administrator and mysql-query-browser. so i guess they need to be ported to 24 if you want to have a go at it feel free. ill help as much as i can.
Well, I looked at mysql-administrator 1.1.4 and mysql-query-browser 1.1.17: they both already use the new 2.4 API and i successfully built them on Rawhide (mysql-query-browser required ./configure --with-gtkhtml=libgtkhtml-3.8)... Were you specifically trying to build older versions ? (and if so, why?).
Those versions have been released since i started working on them when i started mysql-administrator was 1.1.2 and mysql-query-browser was at 1.1.14
Excellent, i'll close this bug then. Michael, I've CVS removed the old 20 packages (gconfmm20, gtkmm20, libglademm20, libgnomecanvasmm20, libgnomemm20 and libgnomeuimm20) from devel. For reference : http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00936.html
Shouldn't the newer ones in have corresponding Obsoletes: in order to get rid of the removed packages when upgrading to FC5? Eg. "Obsoletes: gconfmm20 <= 2.0.2" in gconfmm26 (always a good idea to use versioned obsoletes when possible even if the version is embedded in %{name} in this case).
Late reply sorry. It's an interesting point, hadn't really thought about it. My first reaction is this might be somehwat overkill. My understanding of the 'Obsoletes' tag is that its usage is somewhat frowned upon, unless it is strictly necessary, such as when a package changes name and the Obsolete is necessary to prevent a conflict with the older name. This is not the case here, since the 20 and 24 APIs of those RPMs were designed to coexist peacefully (like gtkhtml2 and gtkhtml3, for example). So using Obsoletes here would be more of a convenience, to remove unused libraries (assuming the user wasn't using the older ones for some legacy project). But this might be outside the scope of the RPMs. I can imagine that up2date in the future could have an option that lets the user 'remove unused development and/or run-time libraries' that would take care of this.
Obsoletes is bad only when done without specifying a version. If not specified here, upgraders will have an unmaintained (!) package from an earlier distro installed after the upgrade, which may cause problems, confusion and even security issues. The Obsoletes would take care of this, and when done with a version (and preferably a release), people who still need the old package could just bump and rebuild it locally. package-cleanup from yum-utils is BTW one tool to help in getting rid of unused stuff. Anyway, unused is much less bad than unmaintained, especially when the user is not aware of the latter.