Office/ and Utilities/ menu reorganization

[Michael Nottebrock]

On Tuesday, 9. August 2005 03:31, Thiago Macieira wrote:
> Michael Nottebrock wrote:
> >I don't buy any of that. Qt and Kdelibs are binary compatible over long
> >periods of time, making a tarball is a matter of five minutes maximum
>
> I'm sorry, but have you tried?
>
> I tried making a release for Kopete after the MSN server change. 
>
> [...]
>
> It most likely is a lot easier for a small app in extragear.

Yes, indeed it would be (and for a bigger app, too)! You're making the point 
for me here. 

> But you are 
> asking to split a couple of rather large applications from the codebase,
> for developers who have never made a single release. Not to mention that
> configure tests are spread over the whole module, so the configure.in.in
> scripts would have to be adapted.

That is true - all the more reason to become much much more conservative when 
it comes to adding new applications to the mainline modules.

> Another point is that some small apps make no sense being packaged
> separately. Users would never find out they exist.

There are very popular and successful facilities to promote KDE applications 
of any sort - people regularly come up in the kde-freebsd IRC channel and 
tell or ask about applications I, the packager dude, haven't heard of before 
(mostly because I'm too busy with the mainline KDE stuff to really care for 
everything else out there). 

I honestly don't know how small an application would need to be to be 
overlooked that way - people have asked me for help with compiling stuff like 
alternative desktop pager applets for kicker - it doesn't get much smaller 
than that.

>
> >... and it would mean that users only get kile, kdvi, kghostview and
> > kpdf in the end - but not a bunch of very much TeX-unrelated,
> > gratuitous stuff like kpovmodeller, kfax, kruler, kview, the X11 gamma
> > correction kcm module ...
>
> You miss the point. Instead of tracking one dependency, the user and the
> packager now have to track three or more.

That's just not true. Kdegraphics as a whole has many *more* dependencies than 
just kpdf, kghostview and kdvi, and you have to track them all - at least if 
you're a packager.

> Add the complexity of versions: 
>
> (fictitious data)
> kile 2.0 requires kpdf 1.0, kghostview 0.25 and kdvi 1.5
> kile 2.0.1 requires kpdf 1.0.1 to fix a regression
> kile 2.1 requires kpdf 1.0.1, kghostview 0.27 and kdvi 1.6
> etc.

How is that different from the specific requirements from applications in a 
module?

-- 
   ,_,   | Michael Nottebrock               | lofi at freebsd.org
 (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050809/1222267c/attachment.sig>