On Fri, Jun 18, 1999 at 01:06:18PM -0700, Daniel Quinlan wrote: > > No... The package puts a file that needs to be modified by the site (and > > possibly by the individual machine) in /usr/share.. Perhaps the program > > is at fault for doing this. I do know that lintian will generate an > > error on the package should I run it with a conffile in /usr/share. > > The file should probably go into /etc, then.
That's where I've placed it.
> > Should such conffiles be in /usr/share ? If not, where should they be?
> > It's currently symlinked into /etc but I don't much like that idea.
>
> What's the conffile and package?
>
> Sometimes packages put data into /usr/lib or /usr/share which includes
> a small part that may need to be locally configured. For example, the
> magic file may include small localizations. A good solution in that
> particular case is a magic.local file that goes into /etc and the main
> magic file stays in /usr/share.
dfm ...
Package: dfm
Status: install ok installed
Priority: optional
Section: x11
Installed-Size: 744
Maintainer: Joseph Carter <[EMAIL PROTECTED]>
Version: 0.99.2-1
Depends: libc6 (>= 2.1), libglib1.2 (>= 1.2.0), libgtk1.2 (>= 1.2.3-1), xlib6g
(>= 3.3.3.1-1), xpm4g (>= 3.4j-0), zlib1g (>= 1:1.1.3)
Conffiles:
/etc/x11/dfm/system.dfmext 95dc5a38cf23e0da30209c9619b339d1
Description: DFM - The Desktop-File-Manager for X11
DFM is a desktopmanager for linux and other UNIX-OS. Files are shown
as icons and every folder has it's own window. The desktopbackground
is a special folder in the homedirectory.
.
The idea is to write a filemanager like the OS/2 WPS.
The conffile in /etc is pointed to by /usr/share/dfm/dfmext. If there
were the ability to load several files I'd put a stripped down file in
/usr/share/dfm, a file meant to be customized by the sysadmin, and in
addition the already supported ~/.dfmext overrides.
I still think a library that spits mime types based on the file (ala the
file command) and replacing dfmext with similar overridable data about
how the program should treat a given mime type---either based on data
collected from the mime associations we already have or better yet using
that data directly with supplimentary data such as to what icon to show
for a given mimetype and possibly what icon for a particular file..
Of course it's really too bad that we can't keep information like icon
and mime type in the filesystem ... OS/2 was designed nicely in that
regard---but never implemented to its fullest potential. BeOS borrowed
that design element and is using it nicely---but only BeOS has it at the
moment.
It's too bad Be isn't interested in opening any part of their OS..
They'd gain as much as we would, probably more given that a number of
people like myself will never buy a proprietary OS again...
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBE The Source Comes First!
-------------------------------------------------------------------------
"This is the element_data structure for elements whose *element_type =
FORM_TYPE_SELECT_ONE, FORM_TYPE_SELECT_MULT. */ /* * nesting deeper
and deeper, harder and harder, go, go, oh, OH, OHHHHH!! * Sorry, got
carried away there. */ struct lo_FormElementOptionData_struct."
-- Mozilla source code
pgpOKneeUuZ3c.pgp
Description: PGP signature
