Re: Concentrating on existing kde2 ports.

["Christian Edward Gruber" <christian.edward.gruber@gmx.net>]

I'd just like to repeat publicly my appreciation for Marc's and others'
(who's names on whom I'm not clea) work on the shared libs problems which
made this KDE progress and some of my GNUstep work possible.

Upon a base of solid software, OpenBSD now is not only a viable server
platform and client platform, but many of the remaining arguements against
its adoption in commercial settings evaporates with the addition of
industrial strength Desktop environments and application suites.  Granted
there's more work to go, but from an end-user and an advocacy perspective,
this KDE work is a remarkable leap forward.

Thanks also to all the ports contributors who collectively have made OpenBSD
2.8 a platform to which I can finally turn as a serious replacement for
Windows on my laptop and daily workstation environments.  There are pieces
remaining, but we're a long way from 2.3 when I first began trying out
OpenBSD.

regards,
Christian.
----- Original Message -----
From: "Marc Espie" <espie@schutzenberger.liafa.jussieu.fr>
To: "Christian Edward Gruber" <christian.edward.gruber@gmx.net>
Cc: <ports@openbsd.org>
Sent: Sunday, December 17, 2000 9:02 PM
Subject: Concentrating on existing kde2 ports.


> I'm finally catching up on kde ports...
> I hope I won't forget anything, since I have my own work, Christian and
> Maurice Nonneke's to merge, sometimes multiple times with intermediate
> versions.
>
> Everything is probably not going to work outright.
>
> Instead of having MORE kde ports, I would like people to concentrate on
> fixing outstanding issues. Namely, it would be cool if kdm were to work
> (right now, it does not).
>
> It could also be very useful to sub-package kdebase. For instance, except
> for testing ports, the only part of kde2 I currently use it konqueror.
> A subpackage that only installs the parts that konqueror needs could
> be handy (as some people will say, with reason, that kde2 is just too big
> for `just the web browser').
>
> Providing more useful configuration (running kapplnk and stuff, doing
> intelligent things with our ports tree) also comes to mind...
>
> I believe we can ditch kde1 at some point in the near future. kde2
> appears to become reasonably stable. In six months times, all issues will
> probably have been fixed.
>
> Hunting down the few apps in the ports tree that depend on kdelibs1 and
> checking whether an updated kde2 version exists could come in handy...
> kde1 conflicts with kde2. Note also that kde1 depends on qt1, which still
> has a TrollTech licence, hence can't go on CDs, whereas kde2 looks to me
> like a prime candidate for the next release (it wasn't included in 2.8
> because of its youth and various problems).
>
> Cleaning up patches and feeding them back to the kde team also comes to
> mind (I ought to take care of libtool issues reasonably soon).
> A class that builds on mkstemp and is easy to use is probably the right
> way to solve all temporary file issues (kde does have a tempfile class,
> but it necessitates modifying code to work. Namely, it creates temporary
> anonymous files that it unlinks right away).
>
> Right now, the kde2 ports don't have actual MAINTAINERS, mostly because
> of their sizes. Well, I spent some time fixing libtool and C++ details,
> but I don't want actual maintainership for those ports. I believe that
> shared maintainership (like we did we teTeX a while back) might be the
> key: keeping ports as maintainer is a good way to ensure no-one will move
> their asses, but the ports themselves are a bit daunting.
>
>