[kde-freebsd] [HEADS UP] QT4.4 RC and KDE4.1 Alpha

[David Naylor]

On Friday 02 May 2008 23:12:43 Danny Pansters wrote:
> Hi folks,
>
> On Wednesday 30 April 2008 17:02:47 Thomas Abthorpe wrote:
> > On Wednesday 30 April 2008 05:33:40 Martin Wilke wrote:
> > > And another problem (not really serious but should be discussed)
> > > is that I want to rename some ports:
> > >
> > >  kdepimlibs ->          kdepimlibs4
> > >  kdebase-runtime ->     kdebase4-runtime
> > >  kdebase-workspace ->   kdebase4-workspace
> > >  kdenetwork     ->      kdenetwork4
> > >  kdeartwork     ->      kdeartwork4
> > >  kdeadmin       ->      kdeadmin4
> > >  kdeutils       ->      kdeutils4
> > >  kdemultimedia  ->      kdemultimedia4
> > >  kdeedu         ->      kdeedu4
> > >  kdetoys        ->      kdetoys4
> > >  kdegraphics    ->      kdegraphics4
> > >  kdesdk         ->      kdesdk4
> > >  kdewebdev      ->      kdewebdev4
> > >  kdegames       ->      kdegames4
> > >
> > > The rename makes more sense for the future with KDE5.
> > > (Hopefully not in the next 5 years)
> > > Does anyone have anything against it?
> >
> > I'm with Miwi on this one, I would like to see the respective kde ports
> > postfixed with the major rev number, it is waaaaa-aaaay less confusing,
> > and as he says, poises us well for the future with kde5 et al.
> >
> >
> > Thomas
>
> I agree too, it's the lesser evil. The same question is coming with 3rd
> party apps:
Seconded

> I've been looking a little bit at kmplayer and gtk-qt-engine for kde4, and
> there too I pretty much already reached the conclusion that there will be
> no other option than to start calling them kmplayer4 etc, if they are to
> coexist with their kde3 older versions for a significant time (and let's
> not kid ourselves, we're still looking at ~ a year in that respect).
I think ideally it would be nice if we could say that kde4 and kde3 just 
conflict (which they do!) however we should be realistic.  Where is an 
alternative approach...

Scenario 1
--------------
Have kde3 and kde4 conflict.  This makes life really easy and those who do not 
depend on or require kde3 do not have to put up with all the horrible 
suffixes.  Straight and simple (the way to go :-)

Scenario 2
--------------
Put kde4 in its own suffix (i.e. /usr/local/kde4).  This avoids a lot of 
problems with kde3.  (A possible alternative is to have kde4 in subprefixes, 
such as /usr/local/bin/kde4, /usr/local/lib/kde4, etc).  Either case I think 
CMake will be able to do it with ease.  

The great thing is we could have both scenarios in ports and one could switch 
between them with a knob (i.e. WITH_KDE3 or WITHOUT_KDE3?).  With a bit of 
genius it would happen seamlessly :-)

> I'm afraid that later on at one point in time (when qt3/kde3 go EOL in
> ports) we're probably going to have the repocopy fest of the decade,
> because then probably everyone and their sister are going to want to rename
> the foo4 back to just foo. I think something like this is going to be
> unavoidable (it could be nicely synch'd with the start of a ports freeze as
> the time to do the repofest arrives).
One option (which I doubt is feasible) is to have both kde3 and kde4 suffixed 
with sym-links to the `proper' name of the binary, that way a switch from 
kde3 to kde4 results in a change of sym-links.  Or alternative leave kde3 and 
when it goes EOL replace the binaries with sym-links to their kde4 
equivalents.  

Comments?

> What are people's thoughts about this, 3rd party apps/libs that will have
> to coexist in different versions for kde3/4 for (quite) a while? It may be
> a good time now to establish some guidelines for porters.
CMake may just have some magic that will ease this whole process, I can 
investigate this after my exams (about a month and a half away :-( )

Has anyone spoken to other packages (Gentoo?) and the CMake/KDE developers.  
They might have already have solved this problem for us, or at least have 
good suggestions on which direction to travel (and possibly good hints on how 
to implement it...)

Regards

David


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-freebsd/attachments/20080503/221f2ec0/attachment.pgp