Gentoo Archives: gentoo-dev

From: Danny van Dyk <kugelfang@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] eselect modules
Date: Tue, 16 Aug 2005 19:52:24
In Reply to: [gentoo-dev] eselect modules by Jeremy Huddleston
2 Hash: SHA1
4 Hi Jeremy,
6 (Just a note: the follwing expresses my opinion, i don't speak for the
7 other eselect devs)
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 :-)
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.
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.
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.
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...
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...
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.
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
75 ~ <module>-update, <module>-config, <module>-manager, config-<module>,
76 ~ update-<module> or manage-<module>,
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:
82 ~ kernel-config, profile-config, rc-config, bashcomp-config
84 Btw: Thx for you feedback on eselect. It really appreciated it :-)
86 Danny
87 - --
88 Danny van Dyk <kugelfang@g.o>
89 Gentoo/AMD64 Project, Gentoo Scientific Project
91 Version: GnuPG v1.4.1 (GNU/Linux)
93 iD8DBQFDAkP4aVNL8NrtU6IRAhEkAJ9zqqfiaruWxy+PQ1e57ybNOcgWIgCff6Y8
94 q0TidAU1r1rlCb6uuAwRiMM=
95 =BY+s
96 -----END PGP SIGNATURE-----
97 --
98 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] eselect modules Ciaran McCreesh <ciaranm@g.o>
Re: [gentoo-dev] eselect modules Jeremy Huddleston <eradicator@g.o>