Okular moving

[Gary L. Greene, Jr.]

On Monday 20 November 2006 15:05, Leo Savernik wrote:
> Am Montag, 20. November 2006 13:30 schrieb Kevin Krammer:
> > > The really big problem with this approach is that people have to know
> > > beforehand which application they have to install to get feature X.
> >
> > Actually no, that's the point of a package dependency, isn't it?
> > If a user installs the KDE desktop package, e.g. usually a meta package
> > called "kde" or "kde-desktop", it will depend on the packages that make
> > up a full-featured KDE desktop. If it does depend on kdegraphics or just
> > KPDF is not a teeny weeny bit different to the user at install time, but
> > gets them less crowded K-menu at runtime.
>
> Yeah, but then we're totally at the mercy of distributors to assemble
> suitable "kde" metapackages. Some will get it right and others will blow
> it.
>
> The current way as I understand it for KDE 4 is to consolidate the best
> apps into their respecitive kde{network,pim,graphics,multimedia,...}
> packages and have them released as "KDE - The Desktop Environment".
> Duplicates go to
> kde{extragear,playground,blackhole,whatever-else-not-being-released}.
>
> The current grouping gives invaluable hints to packagers which applications
> to bundle into meta-packages. If essential applications are moved out of
> "KDE - The Desktop Environment", we again have to rely on distributors to
> grab those essentials from KEG and link them in their meta-packages.
>
> Even worse, it will lead to a segregation of our user base as distributor x
> may choose suitable application A, while distributor y may choose suitable
> application B for the same purpose.
>
> This blurs the line between packages tightly intertwined with "KDE - The
> Desktop Environment" and externally developed packages with their own
> release schedule which just happen to use the KDE infrastructure.
>

This is STILL going to happen, no matter if you do it the way you propose. 
Many distributions think that they have the "killer" combination of apps for 
a "desktop *NIX" so I really doubt that this policy shift will help at all.

> [...]
>
> > Anyway. Since source repository organisation currently implies
> > installation modules and this is not likely to change anytime soon, we
> > should just make KEG an official module and have it released
> > (additionally to their own intermediate releases) as one hugh package
> > (poeple other than me seem to like hugh packages) whenever KDE releases.
>
> KEG has become way too big to install it as a whole. Given how bitchy it is
> to extract out a single app and build it (has this improved with cmake?),
> and given that users who want to gain functionality selectively again have
> to know the name of the package, this suggestion seems to lead to more
> disadvantages than advantages.

Never been an issue for me, but then, I don't do a mega-build of KEG, I do 
them individually as they are released on their respective web sites.

> > Everybody gets "everything of KDE" and everybody is happy and we do no
> > longer need to discuss into which module to put apps.
>
> <irony detector ringing>
>
> mfg
> 	Leo

-- 
Gary L. Greene, Jr.
Sent from: uriel.tolharadys.net
 18:28:22 up 1 day,  1:49,  7 users,  load average: 0.17, 0.22, 0.18
=========================================================================
Volunteer Developer for the PhoeNUX OS open source project
    See http://www.phoenuxos.com/ for more information
=========================================================================

Please avoid sending me Word or PowerPoint attachments.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061120/c7f773af/attachment.sig>