[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 
comparason.

> 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
wasted space.  
 
> > > 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.  

> 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

-- 
----------------
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: