Bug 170211 - no gtkmm20 package for FC4
no gtkmm20 package for FC4
Product: Fedora
Classification: Fedora
Component: gtkmm20 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Denis Leroy
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2005-10-08 23:21 EDT by Dennis Gilmore
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-27 16:10:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dennis Gilmore 2005-10-08 23:21:50 EDT
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: 
Steps to Reproduce: 
1.  try to build package for FC4 using gtkmm20 
Actual results: 
nuild fails cant find gtkmm20 
Expected results: 
build finds gtkmm20  and succeds 
Additional info:
Comment 1 Denis Leroy 2005-10-09 21:45:30 EDT
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.
Comment 2 Michael Schwendt 2005-10-10 05:32:30 EDT
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.
Comment 3 Dennis Gilmore 2005-10-10 09:43:03 EDT
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 
Comment 4 Denis Leroy 2005-10-27 05:14:34 EDT
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?).
Comment 5 Dennis Gilmore 2005-10-27 07:33:51 EDT
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  
Comment 6 Denis Leroy 2005-10-27 16:10:06 EDT
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 :

Comment 7 Ville Skyttä 2005-10-27 16:25:59 EDT
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). 
Comment 8 Denis Leroy 2005-11-05 16:39:20 EST
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.
Comment 9 Ville Skyttä 2005-11-06 06:00:22 EST
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. 

Note You need to log in before you can comment on or make changes to this bug.