Bug 43360 - pcre and mimelib should not be in kdesupport
Summary: pcre and mimelib should not be in kdesupport
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kdesupport   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-03 21:47 UTC by Jay Berkenbilt
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-06-03 21:47:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jay Berkenbilt 2001-06-03 21:47:16 UTC
This is a gripe about the kdesupport package.  I think that, if you think
about this, you will agree with my comments and make this change for a
future release of RedHat.

The kdesupport package contains libpcre (perl compatible regular
expressions) and mimelib.  The very description of the kdesupport package
says that it contains libraries that are used by KDE but are not part of

This packaging decision is most unfortunate since pcre and mimelib are
packages in their own right.  It is pure happenstance that they are
included in RedHat only to support KDE.  The Right Thing [tm] to do is to
package pcre and mimelib (and pcre-devel and mimelib-devel) as their own
packages.  Then make kdesupport contain just the kde.sh and kde.csh files. 
If you really want, make kdesupport depend upon mimelib and pcre, but
that's not even really necessary because rpm does a good job of
automatically making things dependent upon shared libraries that they use. 
Instead, just include pcre, pcre-devel, mimelib, and mimelib-devel in the
appropriate groups for installation so that they get installed when someone
checks kde and/or developer.

Although I think these arguments stand on their own and that RedHat will
agree with them once they are presented in this way, I should mention that
I'm not just doing this to pick a nit.  I've been using PCRE in my
development environment for years.  It is a great library.  I have my own
home-made rpms for it that I've been using for some time.  My company's
entire production environment is based on RedHat Linux and we release all
our own internal production software with rpm.  I now have to tell my users
that they have to install kdesupport in order to use my software which has
nothing to do with KDE.  kdesupport pulls in along with it qt, audiofile,
and gdbm which have nothing to do with pcre.  The only way to avoid these
uneccessary packages being installed is to either use --nodeps (a practice
I actively discourage in our facilities) or for me to build my own pcre
rpms that are mutually exclusive with kde.  As neither option is
exceptable, we're just requiring that kdesupport be installed.

As a general rule, if one package requires another package, the subordinate
package should be released as its own thing, not just lumped inside of
another package.  What will you do if something in gnome wants pcre in the
future?  Surely you don't want to make gnome require kdesupport!  RedHat
has handled this type of situation correctly in the vast majority of
cases.  For example, librep is required, to my knowledge, only by sawfish
and its related tools, but it is available as a package by itself.  Perhaps
that's because the sawfish developer has done this packaging on his own,
but either way, it's the right thing to do, just as packaging pcre by
itself is the right thing to do.

Thanks for your consideration.

Comment 1 Bernhard Rosenkraenzer 2001-06-27 13:07:18 UTC
I've made pcre a separate package the day after the 7.1 release - the only 
reason it was ever in kdesupport is that it was added after packaging freeze 
("no new packages because the translators need to translate descriptions"), 
but it was needed for kjs to work properly.

mimelib is currently still in kdesupport, but has been moved in the KDE CVS 
tree, so this will automatically be fixed when we update to KDE 2.2.

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