Hello,

I am interested in the motivation behind using multiple mutually
exclusive packages instead of package options to control certain
software. I am interested because this affects updating
procedures (more on that below).

One example among many is net/snort[-*], which exists in multiple versions:

   snort
   snort-mysql
   snort-pgsql
   snort-prelude

net/snort is just a meta-package depending on either snort-mysql or=20
snort-pgsql. The rest are all mutually exclusive; that is, each of them is=
=20
marked to conflict with all other versions[1].

What is the reason for having multiple conflicting versions of snort,
rather than having a single snort package with mutually conflicting
options?

The one reason I can think off is the ability for other packages to
depend on snort compiled with specific features. Indeed, grepping
through the tree there are a couple of packages that depend on either
snort-mysql or snort-pgsql:

   ./net/oinkmaster/Makefile:DEPENDS+=3D     \
      snort{,-mysql,-pgsql}-[0-9]*:../../net/snort

   ./net/snort-rules/Makefile:DEPENDS+=3D    \
      snort{,-mysql,-pgsql}>=3D2.4.0:../../net/snort

This works thanks to intimate co-operation between the snort packages
(CONFLICT:ing properly) and dependent packages (depending on those
versions supported). The user is prevented from trying to use
oinkmaster or snort-rules in combination with snort-prelude[2].

Given that co-operation between packages is already required to make
this work, how about having the mysql vs. pgsql vs. ... support be an
*option* of the same package, and having packages like
snort-rules/oinkmaster look at that option to decide whether they are
installable? I realize this requires dependent packages to have
intimate knowledge of the inner workings of dependencies, but this is
already the case (see last paragraph).

Here is why I care:

I originally realized this was a problem because it affected
pkgmanager's capability to assemble a correct dependency graph for
packages that depend on this type of package. Because the fundamental
strategy with pkgmanager was to assemble the dependency graph
independently of what is currently installed on the system, it
resulted in the 'default' version of the package being chosen.

This can *mostly* be fixed by having pkgmanager (or other similar
tools) actually consider what is installed on the system; the fact
that e.g. snort-pgsql is installed is an implicit indication that the
user prefers snort-pgsql over snort-mysql.

However, even if this is done, some problems remain. Consider for
example the case of net/snort being moved to the future hypothetical
net-security/snort. In the case where the user actively cares about
snort, it is the user's responsibility to realize that the old package
no longer exists, and choose a new one - no problem.

However, in the case of snort only being installed as a result of
being a dependency, the user's expressed preference of snort package
suddenly vanishes[3]. Worse - suppose the user is actively after two
packages that depend on snort - A and B. Suppose A depends on *either*
version of snort, but B depends specifically on snort-pgsql. Further
suppose A is installed prior to B - suddenly B can no longer be
installed because it will depend on a version of snort (snort-pgsql)
that is in turn unable to install because it conflicts with the
already installed snort-mysql.

One can imagine a tool that automatically detects and resolves these
cases, such that if there is a combination of packages that will not
cause conflicts, that is the combination chosen. But if there are
multiple such combinations, the method still fails to consider the
user's preference among those possible combinations.

This feels generally messy; making the choice *explicit* would (as far
as I can see) eliminate all these problems. Moving a package would
not be a problem because the name of the package option would not
have to change. Any misstakes or procedures performed on the
system (manually or with tools) will not accidentally purge the 'implicit'
preference settings; regardless of what is done to installed packages,
the pkgsrc tree, the mk.conf and optionally the configuration of the tool
being used fully defines which packages should be installed, and the
system can be brought into a fully consistent state regardless.

=46rom the user's standpoint, it would also be more clear what is going on;=
=20
instead of snort-pgsql mysteriously failing, package B can state "net/snort=
=20
with PostgreSQL support is required for this package to work" or similar,
making for a much more informative error message. If one is not knowledgabl=
e=20
of the workings of pkgsrc, attempting to install package B and getting some=
=20
message that A-X conflicts with A-Y is bound to be off-putting.

[1] Excpet that snort-mysql and snort-pgsql do not conflict with
snort-prelude, which I presume is an oversite given that the reverse
is marked as being a conflict.

[2] Whether this is intended I do not know; I am not familiar enough
with snort to know of hand what the 'prelude' stuff is).

[3] Unless there is some special information for use by tools to
realize the 'move', and therefore that net/snort-XXX should be
replaced by net-security/snort-XXX.

=2D-=20
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org