Re: conflicts in Debian Distributions
In article <[🔎] 199810261544.QAA25206@baldwin.rat.se>,
Jack Nutting <jnutting@rat.se> wrote:
>That being said, perhaps there should be a predefined installation selection
>(among the listed configurations you get when you run dselect on a new
>installation) where something as close as possible to "everything" is
>installed. So if there are multiple, conflicting versions of a library or
>tool, the newest stable version would be installed; Where there are
>conflicts between functionally overlapping packages (like smail/sendmail/exim
>as you mentioned above), perhaps it should install none of them, and output
>into a log file some human-readable summary of which conflicting packages the
>user may want to choose from, so they can easily see what they might want to
>go back and install later. Just some ideas...
I don't like the idea of having an "install everything" option.
There are packages that consume much memory or cpu load, or open
security holes that are unneccessary for anybody who does not
explicitely choose those options. For example, courtney induces a
very high load if used in a high traffic network. I wouldn't install
it, except if it's functionality is explicitely needed.
On the other side, sometimes it would be very useful to have conflicting
packets installed next to each other. This is difficult for packets which
need special system resources, e.g. MTA who want to listen to port 25.
But it is definitely possible that somebody wants qmail as incoming MTA
(for security reasons) and sendmail for outgoing messages (for lower
bandwith consumption).
It should be easier for "normal" packages (without daemons, inetd.conf
enties etc.) to have two conflicting packages installed. For example,
I'd like to have gs-alladin and gs installed in parallel; gs-alladin
for it's pdf support, and gs for it's better Epson Stylus Color driver.
But it is not possible because both binaries are named "gs".
What about an option to install binaries under different hierarchies,
for example one under /usr/bin, /usr/lib, /usr/doc etc. with config
files in /etc and variable data; others under /opt/bin, /opt/lib,
/opt/doc, /etc/opt, /var/opt. For binary packages, this look difficult
because of many binaries having hardcoded paths in it. But for source
code packages, it should be possible.
Just an idea... 8-)
Harald
--
Harald Weidner http://www.ifi.unizh.ch/~weidner/
Reply to: