Hello, On Fri, 22 Dec 2006, Luk Claes wrote: > Kapil Hari Paranjape wrote: > >In such a situation it would be incorrect to insist that one of the > >packages use a binary with a different name---because of (1). > > So what's wrong with insisting both of them changing the name?
That we would have two sets of unhappy users instead of one :-)?
More seriously, the name of the binary will figure in other places.
For example "user-mode-linux" uses "slirp" to start network
connections. All users of "user-mode-linux" would have to
re-configure in order to use "/usr/bin/slirp.comm"
> >Currently, the only available solution is to use "alternatives". I
> >know that this is not considered to be the correct use of alternatives
> >which is meant to address different programs providing the same
> >functionality. However, this is an alternative use (sorry couldn't
> >resist :)) of alternatives. Perhaps we could use a different
> >namespace like "choices" instead of "alternatives" as a way of
> >distinguishing the objectives. The actual mechanisms could be similar
> >(or even identical) to that of "alternatives".
>
> No, that's no solution because later on some package might provide a
> slirp binary which would be a real alternative...
Perhaps I was not sufficiently clear about "choices".
We can use the symlinks:
/usr/bin/slirp -> /etc/choices/slirp -> /usr/bin/slirp.comm
Now suppose we get two programs that give us /usr/bin/slirp.comm.
Then we have:
/usr/bin/slirp.comm -> /etc/alternatives/slirp -> /usr/bin/slirp.comma
Since the namespaces are separated this would not create a problem.
By using the same "mechanism" I meant that the programs like
"update-alternatives" could be used with minor modifications.
Regards,
Kapil.
--
signature.asc
Description: Digital signature
