1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Hi Jeremy, |
5 |
|
6 |
(Just a note: the follwing expresses my opinion, i don't speak for the |
7 |
other eselect devs) |
8 |
|
9 |
Jeremy Huddleston schrieb: |
10 |
| I've recently updated opengl-update to use the eselect framework. I |
11 |
| think the team has done a great job as it was extremely easy to port the |
12 |
| bash script to an eselect module. However, when I placed it in the |
13 |
:-) |
14 |
|
15 |
| portage tree, it sparked a little bit of a policy discussion between |
16 |
| myself and the core eselect devs on how to best include modules in the |
17 |
| tree, so I'd like to let other devs chime in as well. |
18 |
[snip] |
19 |
| The eselect developers want to keep all eselect modules in their svn |
20 |
| repository and distributed through a single package (app-admin/eselect). |
21 |
| Their main reasons for this are better QA and less overhead for releases |
22 |
| and merging. |
23 |
My opinion is this: Keeping eselect modules inside eselect's SVN repo |
24 |
results in: |
25 |
a) More eyes reading the code (read: QA) |
26 |
b) The possibility to change all modules in one move in case we change |
27 |
~ something like a default behaviour, or function names, etc. |
28 |
|
29 |
Having all modules in the same repository is imho more important than |
30 |
having only one package to distribute it. I can happily live with |
31 |
x11-base/opengl-update installing a module inside |
32 |
~ /usr/share/eselect/modules |
33 |
and creating a symlink for opengl-update. |
34 |
|
35 |
| I have a problem with this policy because: |
36 |
| 1) Stability of the modules should not be tied to stability of the core |
37 |
| package. Basically, I'd like to determine when my modules get pushed |
38 |
| into stable without considering how it'll effect the eselect modules of |
39 |
| other developers. Similarly, I don't want bugs in another module |
40 |
| holding up my module from going into stable. |
41 |
Understandable. |
42 |
|
43 |
| 2) Not all users will want all modules. The goal of the eselect project |
44 |
| is to provide a framework to replace java-config, motif-config, |
45 |
| gcc-config, binutils-config, opengl-update, etc, but not all users will |
46 |
| need all modules. |
47 |
I agree here as well... |
48 |
|
49 |
| 3) Some modules require extra files (opengl-update installs header |
50 |
| files, gcc-config installs a wrapper, etc), and the app-admin/eselect |
51 |
| package is not the correct place to provide these files. |
52 |
jupp... |
53 |
|
54 |
| Also, what should the correct way to introduce these modules into |
55 |
| portage? |
56 |
| Should we keep them in the packages they're replacing |
57 |
| (x11-base/opengl-update)? |
58 |
| Should we place them in a new package in the same category as the script |
59 |
| they're replacing (x11-base/eselect-opengl)? |
60 |
| Should we place them in app-admin/eselect-<module name> or perhaps |
61 |
| app-eselect/<module name>? |
62 |
I'd prefer app-admin/eselect-<modulename>, but i could happily live with |
63 |
app-eselect/<modulename>. But i don't think that we need a whole new |
64 |
category for eselect modules. Not right now, and probably not in future, |
65 |
either. |
66 |
|
67 |
| Note that for backwards compatibility in all cases, |
68 |
| x11-base/opengl-update will RDEPEND on this eselect module and install a |
69 |
| backwards-compatible frontend to the eselect module until all packages |
70 |
| in portage have been updated to use the eselect module instead. |
71 |
Jeremy, do you know about the 'old-script-name' feature that Ciaran |
72 |
introduced? |
73 |
By symlinking /usr/bin/eselect to one of these |
74 |
|
75 |
~ <module>-update, <module>-config, <module>-manager, config-<module>, |
76 |
~ update-<module> or manage-<module>, |
77 |
|
78 |
a call to it will be handles as if the user called 'eselect <module>'. |
79 |
You might probably want to consider this for your opengl-update package. |
80 |
app-admin/eselect currently installs these symlinks automatically: |
81 |
|
82 |
~ kernel-config, profile-config, rc-config, bashcomp-config |
83 |
|
84 |
Btw: Thx for you feedback on eselect. It really appreciated it :-) |
85 |
|
86 |
Danny |
87 |
- -- |
88 |
Danny van Dyk <kugelfang@g.o> |
89 |
Gentoo/AMD64 Project, Gentoo Scientific Project |
90 |
-----BEGIN PGP SIGNATURE----- |
91 |
Version: GnuPG v1.4.1 (GNU/Linux) |
92 |
|
93 |
iD8DBQFDAkP4aVNL8NrtU6IRAhEkAJ9zqqfiaruWxy+PQ1e57ybNOcgWIgCff6Y8 |
94 |
q0TidAU1r1rlCb6uuAwRiMM= |
95 |
=BY+s |
96 |
-----END PGP SIGNATURE----- |
97 |
-- |
98 |
gentoo-dev@g.o mailing list |