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. --
Attachment:
signature.asc
Description: Digital signature