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

List:       kde-devel
Subject:    Re: Request For Comments ( was Re: Redhat kde package config)
From:       Troy Engel <tengel () sonic ! net>
Date:       1999-09-01 2:36:37
[Download RAW message or body]

(heh, you know me and my loud mouth, I always have a comment :-)

Duncan Haldane wrote:
> 
>     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?

I have installed kde for a number different systems (laptops, desktops,
servers) and perfer the subpackage breakdown of all the apps.  This lets
me install what I need to - laptops especially, where sometimes you're
out of harddrive space and need to be really picky.

>     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?

I don't think this will conflict with my efforts at all.  Look at ktop
for a prime example of how it works together nicely; ktop is provided in
KDE 1.1.1 packaging, but a rather older version.  I have been releasing
newer versions of it (as often as Chris released) and it's a simple
matter for folks to "update" their stuff.

One thing I could do to make things better is try and add Obsoletes:
tags if a package is updating an official one.  I guess I shoulda been
doing that all along... (shame on me)

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

My personal choice is (C).  My professional choice is try and work out
something with Redhat to ensure we don't confuse users anymore,
especially the new ones.  I see from the other thread Preston is
planning on making RPMs for the new release.  So, what can we do to get
Duncan and Preston packages to be nice to each other, so that Troy
packages aren't confusing for new folks?  The entire reason for RPMs
(well, ok, not the entire reason but a big one) is ease of use and
brain-dead installation of new programs.  RPM has saved me many a time
from accidentally whacking my system.  If we fragment another distro,
what do we tell users?  And, what should the RPMs I make do?

> (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..
> 
>        Comments on this issue (required rpm and qt versions), please.

If this is done, we should mirror the official RPM upgrade packages from
ftp.redhat.com, so that a user doesn't have to go chasing after them. 
It's the nice thing to do, if nobody minds. :)

-te

-- 
Troy Engel
GPG KeyID: DF3D5207
GPG Key Server: http://pgp5.ai.mit.edu/pks-commands.html
GPG Fingerprint: BDF5AC2BDFB8058C 4FBDCEE6E16BB199 DF3D5207

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