[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Request For Comments ( was Re: Redhat kde package config)
From:       Duncan Haldane <f.d.m.haldane () mciworld ! com>
Date:       1999-08-31 21:20:30
[Download RAW message or body]

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 <redhat-rpms@kde.org>.

    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@kde.org>

Duncan.

[prev in list] [next in list] [prev in thread] [next in thread]