On Tue, 8 May 2001, Norbert Nemec wrote:
> Sorry, I disregard that subject line - in agree with that solution except for
> one detail:
>
> As a sysad, I do not like to edit anything beneath /usr by hand (exception:
hmmm, /usr could also be mounted read-only?
> /usr/local) up to now, the only reason to ever do such a thing was to
> workaround
> bugs until a new debian-package came out. Usually, in backing up a complete
> system, I regard it to be completely restorable with only the original
> packages
> at hand and a backup of everything except /usr. (again, /usr/local is the
> exception) No idea whether that idea is compliant with the policy, but up to
> now, it has always worked.
>
> Therefore, the correct place for the system wide override directory should be
> /etc/kde/{applnk,mimelnk,servcises,servicetypes} which might well be empty by
> default. Actually, I believe having both /usr/share/kde/applnk and
> /usr/share/applnk with different meaning would cause a lot of confusion. IMO,
> the second option should be dropped and replaced by a /etc/kde/applnk (empty
> by
> default)
Having them in a single directory feels right, maybe...
/etc/kde2/share locals and overrides
/usr/share default Debian-KDE supplied
For subdirs...
applnk and mimelnk most likely to be tweaked
(mime-types, magic and default apps)
templates I've only added stuff here, but someone may
want to modify the existing templates
? service{s,types} why would a sysadmin want to touch these?
So I would want to do...
/usr/share/{applnk,mimelnk,templates}
...and...
/etc/kde2/share/{applnk,mimelnk,templates}
...which leads to some questions...
The applnk stuff will be handled by /etc/menu-methods/kdebase and
KDE (kbuildsycoca). Is that correct?
Who would take care of the mimelnk, services, and servicetypes stuff -
KDE (kbuildsycoca) or Debian (tagging along with menu-method/kdebase)?
Can templates be handled like mimelnk, etc.?
- Bruce
