Re: packaging updates/changes/customization for woody's release
On Mon, 7 May 2001, Ivan E. Moore II wrote:
> > > I'd like all of you who have done some sort of customization of your KDE
> > > installations to look over it and figure out what bits would be good for
> > > Debian. What parts would enhance the KDE default installation. What
> >
> > My vote goes on configuring /usr/share/applnk as config files, so that they
> > don't get clobbered by an upgrade. (i.e. moving them to /etc/kde2/applnk or
> > something)
>
> then you have to deal with left over files (*.dpkg-old, etc...) which if
> not removed will cause duplication in menus and KDE doesn't like duplication.
> I'll attempt this one more time. The last time I tried this it caused alot
> of problems unrelated to the Debian conffile bits.
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.
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.
> > 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
function.
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.
- Bruce
Reply to: