Hi, I am the packager/maintainer of the RPMs for RedHat 5.x distributed at ftp.kde.org. Red Hat itself (Preston) does not support KDE below RH6.0. This thread seems a good opportunity to ask for feedback for the upcoming 1.(1.)2 release on packaging issues. Sorry for the length of this posting! (1) Since kde-1.1, "rh50egcs" and "rh5x" rpms use a subpackage scheme that produces separate rpms for (almost) every application in kde*, * = (admin,games,graphics, multimedia,network,toys,utils). (exception, a few subsets of small apps are still packaged together). The aim of this scheme was to allow selective installation of KDE components so the rpm user is not obliged to install components (s)he doesn't want. For ease of downloading/installing , *all* the individual application packages are also avalable inside a rpm wrapper ("kde-applications"), and an installation scipt is provided. The installation scheme proved very popular with users, judging from the feedback to . QUESTION: Since Preston's "Official Red Hat" RH6.0 rpms went back to the earlier monolithic scheme, (no subpackages) should I abandon this subpackage scheme scheme for the 1.(1.)2 "rh50egcs" and "rh5x" release?, an return to the monolithic for compatibility? (Hmmm, The redhat-produced 6.0 rpms should probably have "Obsoletes:" tags against my subpackage names since they were out there prior to redhat's decision to include kde in their distribution. This might help in upgrading.) I do provide an unistall script which I recommend using before attempting to upgrade to Preston's rpms supplied with RedHat 6.0. (2) My rpms added some "extra" apps not in the kde distribution: as "extar sources": (kpackage , kdiskfree, ktalk, kclock). It integrated ktalk with ktalkd into a single "kdenetwork-talk" subpackage so the talk subsystem gets installed in a fully operational state. kpackage amd kdiskfree are (I believe) added to the cvs (in kdeadmin and kdeutils) for kde-2, and are seperate subpackages. ktalk really should be integrated with ktalkd in kdenetwork. I just liked kclock, added to the kdeutils-tools package.). QUESTION: Is this OK or should these "extras" be separated out? (or suggest any others to add...?) Is this a problem for Troy Engel's application rpm efforts? (3). I did receive a steady stream of email pleas for RH6.0 versions of my packages from users who for one reason or another didn't want use the packages supplied by RH6.0. It turned out that that my rh5x packages ran OK on RH6.0 (often without rebuilding!), and I updated the helper scripts "use_kde", "kdm_on" and "kdm_off" scripts (supplied as extras by my rpms) to recognize RH6.0 and conform to its new structure of /etc/inittab, /etc/X11/xdm/xsession, etc. Despite the requests, I did *not* release specific "rh60" versions of my 1.1.1 rpms, and even included a warning that they were not intended for RH6.0, but some users used the "rh5x" successfully on RH6.0 anyway. QUESTION: I have in fact built and tested "rh60" RedHat-6.0-specific versions of my kde-1.1.2(pre) packages for personal use. What attitude should I take about releasing these if I get requests for them? (The install script detects redhat-6.0, and now specifically asks if installation to /usr/ rather that /opt/kde is desired). Possible policies are (a) Don't release them under any circumstance, it would cause confusion: (b) Make them available in the "contrib" section of ftp.kde.org (c) Offer them along with the "rh50egcs", "rh5x", versions in the usual place at ftp.kde.org. I don't really understand why some users didn't want to use Preston's rpms. Perhaps it was the /usr/ vs /opt/kde thing, or the "1.1.1pre2" initial release with RH6.0. My own experience with "Official RH6.0 KDE" was that it was not made obvious enough how to replace GNOME by KDE, (after an installation choice of GNOME to see what it was like), and a key component for me (kdvi) was totally broken by Glibc-1.1. (But the RH5.2 binary worked on RH6.0 - this was a case where the subpackage scheme was extremely helpful, so I personally used my own packages rebuilt on RH6.0) (N.B. I have fixed this kdvi problem for 1.(1.)2 by upgrading the KDE_1_1_BRANCH cvs with a newer version of the kpathsea library). (4) In my current rh5 test rpms, I have required rpm-3.0 or greater (as opposed to 2.5). Thus the RH5.x user will be required to first update his/her rpm version before installation. (Its a RH 5.x Official update) Is this desirable? (I though so, but.. feedback would be useful); this is mainly because of the inclusion of kpackage as an "extra" in my release. I continue to build against qt-1.42 (as opposed to qt-1.44) for the RH 5.x rpms, though (So a qt update is *not* required). Comments on this issue (required rpm and qt versions), please. On 31-Aug-99 pbrown@redhat.com wrote: > On Tue, 31 Aug 1999, Troy Engel wrote: > >> This brings about a difficulty - what are RedHat's packaging plans for >> 1.(1.)2 release? Will they do it? Will they just forget about it, and >> users rely upon the KDE team? Will the KDE team produce /opt RPMs, then >> RedHat come out a month later with their own? > > We will of course be making 1.(1.)2 packages available for Red Hat Linux > 6.0. Comments can also be sent privately to Duncan.