On Thu, 2005-01-20 at 16:17 +0100, Dieter Baron wrote:
> In article <1106222131.1075.41.camel@dawn.local> Julio wrote:
> : When a package is removed, the alternatives system checks if it was
> : the current setting for a class; in such case, it tries to fall back
> : to another one in the same class.  If none is found, the class is
> : automatically removed.
> 
>   I think, the choice should be recorded, so if the package is later
> added again, it is selected automatically.  Updates are often done by
> removing the old versions of packages and then installing the new
> versions.  I think the selected alternative should be the same after
> such an update.

Hmm right.  I'll see what I can do.

> : Also note that the links go this way: /usr/pkg/bin/vi -> sysconfdir/vi
> : -> /usr/pkg/bin/nvi.
> 
>   I would prefer collecting all alternatives under one subdirectory of
> sysconfdir (such as sysconfdir/alternatives).  Also, simply using the
> basename of the file as the name of the symlink under sysconfdir might
> lead to conflicts.

Yes well, sorry for the terminology.  When I wrote sysconfdir, I was
referring to PKG_SYSCONFDIR, which is PKG_SYSCONFBASE/PKG_SYSCONFSUBDIR,
and the actual value for the subdir part is 'alternatives'.

> :  sysconfdir is used here so that this can be
> : configured on a system basis if sharing /usr/pkg.
> 
>   This is problematic: if nvi is selected as vi on system A, and on
> system B -- which shares /usr/pkg with system A -- nvi is deleted,
> system A is left with dangling symlinks.

True... but any better idea?

I only see a solution to this, which is to use wrappers instead of
links.  This way, the wrapper might check if the expected program
is available, and fall back to another one in case it's not.
Dunno if it's worth the effort.

> : What do people think?  I would like to get this finished and committed
> : soon, if there are no big objections.
> 
>   Would it be possible for a package to depend on a alternatives
> class?  For instance, foo depends on vi, so either nvi or vim have to
> be installed, but foo does not care which one?  If so, this sounds
> like a cleaner solution to the bothersome {nvi,vim} style
> dependencies.

These are what's commonly known as "virtual packages".  It could be nice
to have them, but there were some problems WRT its implementation.
I don't remember which they were exactly, but you can look for the
discussion that took place here not so long ago.

Cheers,

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/