1 |
On Thu, 4 Nov 2004 15:45:39 +0000 |
2 |
Ciaran McCreesh <ciaranm@g.o> wrote: |
3 |
|
4 |
> Say we have a group of packages. For the sake of argument, we'll |
5 |
> call them 'vim', 'nvi', 'elvis' and 'vi'. Each of these packages |
6 |
> provides a binary with the same name as the package. So far no |
7 |
> problem... |
8 |
> |
9 |
> Now let's say that each of these packages were clones or |
10 |
> derivatives of a traditional unix package, which provided |
11 |
> binaries named 'vi', 'view' and 'ex'. A user installing any one |
12 |
> of these packages would expect to be given convenience symlinks |
13 |
> which would allow them to access the packages via the |
14 |
> traditional names. Suddenly we have a problem -- what if a user |
15 |
> has more than one of these packages installed? |
16 |
|
17 |
I would do something like this: |
18 |
|
19 |
1) Write an eclass that deals with that issue in a generic way. |
20 |
Lets call it alternatives-symlink.eclass. What are the different |
21 |
alternatives is declared by the ebuild using an env var, for |
22 |
instance: |
23 |
ALTERNATIVES="/usr/bin/vi:vim /usr/bin/view:vim /usr/bin/ex:vim" |
24 |
(you can also use absolute path in second hand of each |
25 |
declaration if needed.) |
26 |
|
27 |
The eclass would provide 4 functions: |
28 |
|
29 |
- declare_alternative(): it takes two arguments. Its purpose is |
30 |
to maintain a file where are declared all available alternatives |
31 |
on the system(for instance "/var/lib/portage/alternatives"). This |
32 |
file is like this: |
33 |
/usr/bin/vi nvi vi.system |
34 |
/usr/bin/view nvi view.system |
35 |
/usr/bin/ex nvi ex.system |
36 |
When called with "/usr/bin/vi" and "vim" as arguments, |
37 |
declare_alternative() will add "vim" to the first line. Also, if |
38 |
/usr/bin/vi does not exists, it is created as a symlink on vim. |
39 |
|
40 |
- pkg_postinst(): it's a loop on $ALTERNATIVES that makes all the |
41 |
appropriate declare_alternative() calls. It also print an einfo: |
42 |
einfo "To use ${PN} as default for all its alternatives, try:" |
43 |
einfo " # alternatives-config -s ${ALTERNATIVES}" |
44 |
|
45 |
- remove_alternative() is a function that remove an entry in the |
46 |
alternatives base. If the removed alternative was still in use |
47 |
(ie. linked), it fixes the link using an other entry and ewarns |
48 |
the user. |
49 |
|
50 |
- pkg_postrm() that iterates on ${ALTERNATIVES} to call |
51 |
remove_alternative(). |
52 |
|
53 |
|
54 |
2) write a generic "alternatives-config" tool to allow users |
55 |
choosing among all the available alternatives that are in |
56 |
/var/lib/portage/alternatives. Some classical usages would be: |
57 |
# alternatives-config --list |
58 |
* Available alternatives: |
59 |
/usr/bin/vi: vim nvi [vi.system] |
60 |
/usr/bin/view: vim [nvi] view.system |
61 |
/usr/bin/ex: [vim] nvi ex.system |
62 |
(ie, list all available alternatives, with the current one in |
63 |
brackets) |
64 |
# alternatives-config --set /usr/bin/vi:vim /usr/bin/view:vim |
65 |
* Symlinking /usr/bin/vi to vim |
66 |
* Symlinking /usr/bin/view to vim |
67 |
(ie., set some of the alternatives to your favorite choice) |
68 |
|
69 |
> Oh, and to make it even more fun we'll say that certain |
70 |
> non-Linux systems already provide a binary with the traditional |
71 |
> name... |
72 |
|
73 |
That's the "*.system" above. In declare_alternative(), if a target |
74 |
/path/to/foo already exists, then it is moved to foo.system. Then, |
75 |
/path/to/foo is linked to foo.system (to not change the default), |
76 |
and `declare_alternative /path/to/foo foo.system` is called to add |
77 |
it as a new entry in the/var/lib/portage/alternatives file. |
78 |
|
79 |
|
80 |
Other random thoughts: |
81 |
- that system can also be used for directories (useful for |
82 |
some libs for instance), not only binary commands |
83 |
- sometimes it would be useful to be able to declare that a set |
84 |
of alternatives must be changed a coherent way (for instance, a |
85 |
command and a lib dir that must be from the same package). I have |
86 |
no idea how to add that feature (i think that's part of where a |
87 |
dedicated "something-config" starts to be really required) |
88 |
- I was suggesting a new eclass, but writing that as an extension |
89 |
to the alternatives.eclass may be a better idea |
90 |
|
91 |
Oh, and seeing more emails coming in that thread, I realize that |
92 |
part of what I suggest is already suggested by others, so sorry |
93 |
for any redundancy. |
94 |
|
95 |
-- |
96 |
TGL. |
97 |
|
98 |
-- |
99 |
gentoo-dev@g.o mailing list |