Re: packaging updates/changes/customization for woody's release
> > 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 :)
like I said before...last time I tried this there were a ton of other problems
which stacked up and caused other problems...dominoes effect.
don't use kdmrc as an example..I have been doing alot of work in regards to
kdm lately and it's not a good example. When was the last time you had
to confirm something like: /etc/kde2/kuriikwsfilterrc or klipperrc
You will be able to override anything I do to these conffiles without even
touching the conffiles if you wish. Write a script that will parse all
the files under /etc/kde2/applnk/* (for example) and gathers the differences
between them and your files and updates your files which you would drop under
/usr/share/applnk. Your files under /usr/share/applnk will overwrite those
that are in /etc/kde2/applnk.
the same will go with mimelnk, services, and servicetypes.
> > > 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.
see above.
> > 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.
[...]
> Here's some...
> - all too often the solution to a problem is "rm -rf ~/.kde"
hmmm...I've only done that twice in the past year...I think that's pretty
good since I've been running alpha/beta software for most of that.
> - or "rm -rf ~/.kde/share/applnk"
now this I've done more often...but this is usually because I end up testing
something for someone else.
> - 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)
so this here would be ok to conffile but not applnk? they both have the
same amount of translations.
> > > 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
- update-menus
> 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?
/usr/lib .../var/lib... let's create a /kde dir and run a few more scripts.
The functionality is already there. and has been there.
this is how I am going to be doing it.
1. all official .desktop files for mimelnk/applnk/services/servicetypes will
go under /usr/share/kde. (ie.. /usr/share/kde/applnk)
They will not be *currently* marked as conffiles.
2. Debian Menu generated files will go where they are currently going.
/var/lib/kde/menu/* and the kdebase menu-method will handle merging
it into the main /usr/share/kde/applnk tree
3. /usr/share/applnk will not be touched by the packages but will instead
be left for the Admin to do whatever they want to with.
If you don't like this you can edit /etc/kderc /etc/kde2/system.kdeglobals
(probably need to hack both) and tell it to use a different directory or
whatever. /usr/share/kde/applnk will be read first and then /usr/share/applnk.
If you want to overwrite (and make sure your changes stay through upgrades)
a config file you drop in a new one in the same directory position under
/usr/share/applnk.
Ivan
--
----------------
Ivan E. Moore II
rkrusty@tdyc.com
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Reply to: