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 it. 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.
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.