Re: packaging updates/changes/customization for woody's release
> Please don't do it. I modify every single .desktop file that comes
> from KDE (all those langs I'll never use are a significant waste of
> disk space and processing time) and it is not fun doing an upgrade
> when they are all conffiles. What concerns me the most though is that
> when you start using your own files in preference to the defaults it
> is easy to lose updates to the defaults that should be propagated into
> the tweaked files.
And this could save you a ton of work. How often do you have to remove
all those lines from every .desktop file...during *every* upgrade. By
conffile'ng all of them you will only have to do your modifications when
one of the .desktop files change...which doesn't happen that often in
> I think this should be handled much like Debian's menu system does
> it... one dir has the defaults, another has the overrides. i.e.,
> Build /usr/share/applnk instead of installing into it.
it's done this way already. /usr/share/applnk is primary,
$HOME/.kde/share/applnk is secondary.
Either way you will still have the same problem your talking about...the
> > > I like to configure file extensions and associations globally, so each new
> > > user can start XMMS with *.ogg, mplayer/aviplay for *.avi (not the KDE
> > > player), mswordview for *.doc, gvim for *.tex, and so on.
> I don't see why /usr/share/mimelnk couldn't be constructed also; aside
> from being accessed indirectly, it is like applnk in form and
This here is the same thing...except I don't see a reason for anyone messing
with any of these files except to add new files or in your case remove
all the extra i18n tags.
> I keep thinking that having all the kdebase applnk and mimelnk files
> in their own package would be good... but that is probably just
> coming from wanting to fiddle with them in isolation.
why? What would you gain from having them in a seperate package?
Ivan E. Moore II
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD