cobaco (aka Bart Cornelis) wrote:
This installer must be non-interactive too.
as above, NOTE:
- ask with debconf at medium priority, which means that only people who want
to be bothered with questions about settings like this will be bothered,
everyone else will get it placed in the first writeable XDG_*_DIR
* an RPM package that can be installed on any rpm-based system. This
installer must be non-interactive.
can anyone on the list confirm wether or not rpm has something similar to
debconf priorities?
I doesn't. RPM has no support for any kind of interactivity during
installation.
This supposes we can come up with defaults that work across Linux
distributions...
Note that freedesktop.org is about free desktops on any (at least free)
system, not specifically Linux.
first XDG_*_DIR that's writeable seems reasonable to me, sofar I haven't
seen anyone saying it would be unreasonable.
I think there were several arguments pointing out that this *is*
unreasonable:
1. The XDG_*_DIR settings are user or even session specific. Thus if you
install according to the XDG_*_DIR settings of some administrative
session, the chosen location may be unrelated to the XDG_*_DIR of a user
session.
2. A searchpath is unsuitable to define the target of an installation.
The result would be too ill-defined. How would this deal with currently
unavailable mount points or network shares? How to diagnose wrong
behaviour (or even define correct behaviour), when executing an
installation twice (by different users or with different histories) may
lead to a different result without a visible clue (like an explicitly
set parameter).
3. It couples two unrelated things. What should be done, if the
XDG_*_DIR a users needs for software installation (e.g. to run some
installation tool) is different from the XDG_*_DIR of the target user
configuration. (This is issue 1. from a reverse angle).
This is about as unreasonable as defining that end user binaries should
be installed into the first (writable) directory in the installing
user's PATH.
The reasonable solutions I can see are:
A. Install into the installation prefix of the application. If that
doesn't integrate into the global menu, then it is the responsibility of
the sysadmin to perform that integration.
B. Do A. and then run a well defined tool (akin to update-mime-database)
to perform the integration. Distros can customize their version of this
tool to honor their preferred locations and/or sysadmin policy.
C. Always install into /usr/local/share. If a distro or admin chooses to
change XDG_DATA_DIRS not to include /usr/local/share, then they
consciously decide against automatically getting new apps into the menu.
Arguably this is against the spirit of the FHS and prefix-oriented
installation, because it misuses /usr/local by mixing data for /opt (or
whereever) -installed software into this location. Usually global
registration of a new service takes place in /etc. OTOH it has been
common existing practice to make files globally available by installing
(or symlinking) them into some place under /usr.
D. As a variation of the preceding: Install into the prefix and them
symlink into /usr[/local]/share.
--
Joerg Barfurth phone: +49 40 23646662 / x66662
Software Engineer mailto:[EMAIL PROTECTED]
Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software http://www.sun.com/software/sunray/
Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
