[Kde-extra-gear] KDE 3.2?

Dirk Ziegelmeier dziegel at gmx.de
Mon May 17 18:48:45 CEST 2004


On Monday 17 May 2004 15:41, George Staikos wrote:
> On Monday 17 May 2004 02:37, Jeroen Wijnhout wrote:
> > >   This is a problem for Kst.  Almost all of our users use KDE 3.1, at
> > > least half of our developers use KDE 3.1, and I don't foresee that
> > > changing any time soon.  Why can't we make a system whereby the
> > > individual applications choose their minimum requirement and are
> > > removed from compilation if those requirements are not met?
> >
> > You are talking about users that run a CVS version of Kst? We discussed
> > this a while ago, the above policy was the result. It's a compromise
> > really, I can understand you want to require KDE 3.1 instead of KDE 3.2
> > as long as possible.
> >
> > Note that the problem only arises for CVS users, packagers can (and
> > should) modify the configure.in.in themselves. This way this problem
> > shouldn't arise for the bulk of the users.
> >
> > If you have a more elegant solution, I would be happy to learn about it.
>
>    I need to discuss with the Kst users and developers to see what they
> think. The problem is that there are regular users who use Kst from CVS,
> including on Mac OS X and other unique platforms that may lag behind Linux
> support in KDE.  There are also users who have locked down platforms and
> changing KDE version is not an option.  Editting scripts may not always be
> easy for them.
>
>    A better solution is to enable or disable on a per-application basis.
Or to fix the MIN_CONFIG parser. It should use the HIGHEST requirement 
desired, instead of the first one it finds. So the MIN_CONFIG(X.Y) could be 
moved from kdeextragear-*/configure.in.in to each configure.in.in of the 
apps. If someone only checks out one app, he exactly gets this app's 
requirement. If you compile the whole package, the highest requirement found 
is used.

Dirk


More information about the Kde-extra-gear mailing list