Re: packaging updates/changes/customization for woody's release
On Mon, 7 May 2001, Ivan E. Moore II wrote:
> > 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
> comparason.
Last time you tried it I ended up having to confirm that I wanted to
keep every .desktop file I customized every time I upgraded (just
like I have to confirm I want to keep my kdmrc every upgrade), it is
far simpler to do:
cd /usr/share
rfl applnk apps mimelnk services servicetypes templates
# of course I've scripted it :)
> > 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.
It is not the same. There is no way for the sysadmin to override a
systemwide [DesktopEntry] like a sysadmin can override a default menu
entry.
> Either way you will still have the same problem your talking about...the
> wasted space.
Not really...
I would delete the default KDE entries after the upgrade.
> > > > 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.
>
> 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.
Here's some...
- all too often the solution to a problem is "rm -rf ~/.kde"
- or "rm -rf ~/.kde/share/applnk"
- each user must beef up the mimetypes KDE apps recognize themselves,
that should be done at the system level (but if you do, the next
upgrade will wipe it out)
> > 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?
...coming from wanting to fiddle with them in isolation.
i.e, put the hypothetical kde-applnk&mimelnk-pkg on hold and impose my
own handling on the situation - I'm not asking for it! - it just pops
into my head every now and then, for a minute or so. :)
Regarding the KDE main menu, this is what is currently happening...
there are seven sources for the K menu:
- KDE default .desktop files
These are installed into /usr/share/applnk, overwriting any
tweaks done by the sysadmin.
- kappfinder .desktop-s
Installed in /usr/share/apps/kappfinder/apps, tweaks are
history after an upgrade.
- sysadmin generated .desktop-s
Dropped in /usr/share/applnk, maybe symlinks into applnk.
- user generated .desktop-s
Dropped in ~/.kde/share/applnk, maybe symlinks into applnk.
- Debian menu entries
Installed into /usr/lib/menu, no need to tweak these.
- sysadmin generated menu entries (new stuff and tweaks)
Place in /etc/menu, overrides stuff in /usr/lib/menu
- user generated menu entries (new stuff and tweaks)
Place in ~/.menu, overrides {/usr/lib,/etc}/menu stuff
there are two views of the K menu:
- system's
/usr/share/applnk -> ksycoca -> K
- user's
/usr/share/applnk + ~/.kde/share/applnk -> ksycoca -> K
to generate /usr/share/applnk:
- KDE defaults are installed in /usr/share/applnk
- sysadmin's menu entries merged with the Debian menu
- Debian menu is translated to .desktop format
- KDEized Debian menu linked into /usr/share/applnk
to generate ~/.kde/share/applnk:
- kmenuedit
- kappfinder
- add a button to the panel
Now...
If the KDE .desktop files were installed into (say)
/usr/lib/kde/share/applnk, and the sysadmin could put stuff into (say)
/etc/kde2/overrides/share/applnk, and /etc/menu-methods/kdebase
(or whatever would be appropriate) did a simple merge of the two
applnk directories (stuff in /etc/.../applnk wins" -- that would be
similar to what Debian's menu system does.
"to generate /usr/share/applnk" would become:
- sysadmin's .desktop entries merged with KDE defaults
- KDE menu mv|cp|ln to /usr/share/applnk
- sysadmin's menu entries merged with the Debian menu
- Debian menu is translated to .desktop format
- KDEized Debian menu linked into /usr/share/applnk
Would it not be as simple as looping over what is in
/usr/lib/.../applnk and checking to see if there is an override in
/etc/...applnk, then mv|cp|ln-ing it?
- Bruce
Reply to: