[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: No reasonable solution


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.




Attachment: signature.asc
Description: Digital signature

Reply to: