| 1 |
Say we have a group of packages. For the sake of argument, we'll call |
| 2 |
them 'vim', 'nvi', 'elvis' and 'vi'. Each of these packages provides a |
| 3 |
binary with the same name as the package. So far no problem... |
| 4 |
|
| 5 |
Now let's say that each of these packages were clones or derivatives of |
| 6 |
a traditional unix package, which provided binaries named 'vi', 'view' |
| 7 |
and 'ex'. A user installing any one of these packages would expect to be |
| 8 |
given convenience symlinks which would allow them to access the packages |
| 9 |
via the traditional names. Suddenly we have a problem -- what if a user |
| 10 |
has more than one of these packages installed? |
| 11 |
|
| 12 |
Oh, and to make it even more fun we'll say that certain non-Linux |
| 13 |
systems already provide a binary with the traditional name... |
| 14 |
|
| 15 |
One way to go about it would be to introduce blocks. This is pretty |
| 16 |
stupid though -- the only conflict is a measly symlink. So... Some |
| 17 |
genius please provide a suggested way to handle this kind of situation |
| 18 |
that doesn't involve any of the following: |
| 19 |
|
| 20 |
* hard coding knowledge of all the packages in a group into every single |
| 21 |
ebuild in a group |
| 22 |
* hard coding lots of lists into a single eclass |
| 23 |
* making one eclass per group of packages affected by this issue |
| 24 |
|
| 25 |
For reference, you might want to look at the existing code in vim.eclass |
| 26 |
for updating symlinks. Note that it's really ugly and doesn't honour |
| 27 |
${ROOT} like it should. There's also alternatives.eclass but that only |
| 28 |
seems to handle SLOTted packages. |
| 29 |
|
| 30 |
-- |
| 31 |
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips) |
| 32 |
Mail : ciaranm at gentoo.org |
| 33 |
Web : http://dev.gentoo.org/~ciaranm |
Archives