Hi to all, I was trying to understand how to associate packages with tasks and I found this page [1] At the end there is a "Duplicated names" section. I think the proposal is suboptimal as it is not working in my field and it is not possible to propagate it upstream. In my experience my collisions are more or less inside the same field, and I think the same applies to other fields as well: how many "score" or "evaluate" tools are out there, that are used as part of some important iterative process? Clearly in this case /usr/lib/blends/<blendname>/bin approach does not work. I also have one case where I have one complete framework of several programs that needs to coexist with another framework whose programs names have ~100% collision rate. So, here is my proposal (Actually it was proposed to me by Thibaut Paumard [3]): 1) install the binary with the original name to /usr/lib/<package>/bin 2) install a small script (possibly named <package>) in /usr/bin this script should provide an interface so that calling: <package> <binary> will grant that any required variable is set to the right value and that /usr/lib/<package>/bin/<binary> is executed; it is also possible to drop extensions in the new interface; 3) ideally add "help" and "path" command, in order to simplify the life of the users. I have implemented this strategy several times now and it is working very well in my experience. Performance penalty is not relevant as all the binaries are intended to perform non-trivial tasks. The approach can be proposed upstream, as it is not very invasive (in my experience it is typical to users to install tools in different directories and then tweak their PATH for every experiment) and provide many advantages, among which: 1) it is possible to simultaneously install otherwise incompatible frameworks; 2) it is possible to grant smooth transitions between the old and new interface; 3) it is possible to implement autocompletion file; 4) it is possible to implement an "help" command that list all the commands available; 5) it is possible to add a "path" command that points to /usr/lib/<package>/bin to simplify experiments configuration, even when using the old interface; 6) it is possible to grant that each tool is executed in an appropriate environment. You can see an implementation of this approach in irstlm package [2]. This example is nice, as: - irstlm has many scripts with extensions that people are using in their own scripts; - it has a "dict" command (so we have a nice conflict with a famous tool); - recently upstream introduced "plsa" and "plsa.sh" commands, so, after extension removal it has a collision with itself; - there are "compile-lm" and "score-lm" commands that are very likely to collide with many other frameworks in this field. Moreover I implemented help command and provided a bash-autocompletion file. Do you think we can add this alternative proposal to [1]? Is there any better place for it? Is it already documented somewhere? Bests, Giulio [1] https://wiki.debian.org/DebianScience/ProblemsToWorkOn [2] https://anonscm.debian.org/cgit/collab-maint/irstlm.git/ [3] https://lists.debian.org/debian-mentors/2012/04/msg00012.html
Attachment:
signature.asc
Description: OpenPGP digital signature