| 1 |
Jeremy Huddleston wrote: |
| 2 |
> I've recently updated opengl-update to use the eselect framework. I |
| 3 |
> think the team has done a great job as it was extremely easy to port the |
| 4 |
> bash script to an eselect module. However, when I placed it in the |
| 5 |
> portage tree, it sparked a little bit of a policy discussion between |
| 6 |
> myself and the core eselect devs on how to best include modules in the |
| 7 |
> tree, so I'd like to let other devs chime in as well. |
| 8 |
> |
| 9 |
> Firstly if you don't know what eselect is, check out: |
| 10 |
> http://www.gentoo.org/proj/en/eselect/index.xml |
| 11 |
> |
| 12 |
> The eselect developers want to keep all eselect modules in their svn |
| 13 |
> repository and distributed through a single package (app-admin/eselect). |
| 14 |
> Their main reasons for this are better QA and less overhead for releases |
| 15 |
> and merging. |
| 16 |
|
| 17 |
QA is my main concern. |
| 18 |
|
| 19 |
> |
| 20 |
> I have a problem with this policy because: |
| 21 |
> 1) Stability of the modules should not be tied to stability of the core |
| 22 |
> package. Basically, I'd like to determine when my modules get pushed |
| 23 |
> into stable without considering how it'll effect the eselect modules of |
| 24 |
> other developers. Similarly, I don't want bugs in another module |
| 25 |
> holding up my module from going into stable. |
| 26 |
|
| 27 |
agreed. |
| 28 |
|
| 29 |
> |
| 30 |
> 2) Not all users will want all modules. The goal of the eselect project |
| 31 |
> is to provide a framework to replace java-config, motif-config, |
| 32 |
> gcc-config, binutils-config, opengl-update, etc, but not all users will |
| 33 |
> need all modules. |
| 34 |
> |
| 35 |
> 3) Some modules require extra files (opengl-update installs header |
| 36 |
> files, gcc-config installs a wrapper, etc), and the app-admin/eselect |
| 37 |
> package is not the correct place to provide these files. |
| 38 |
|
| 39 |
agreed. |
| 40 |
|
| 41 |
> |
| 42 |
> Also, what should the correct way to introduce these modules into |
| 43 |
> portage? |
| 44 |
> Should we keep them in the packages they're replacing |
| 45 |
> (x11-base/opengl-update)? |
| 46 |
> Should we place them in a new package in the same category as the script |
| 47 |
> they're replacing (x11-base/eselect-opengl)? |
| 48 |
> Should we place them in app-admin/eselect-<module name> or perhaps |
| 49 |
> app-eselect/<module name>? |
| 50 |
|
| 51 |
Good question. I don't really have a preference. |
| 52 |
|
| 53 |
> |
| 54 |
> Note that for backwards compatibility in all cases, |
| 55 |
> x11-base/opengl-update will RDEPEND on this eselect module and install a |
| 56 |
> backwards-compatible frontend to the eselect module until all packages |
| 57 |
> in portage have been updated to use the eselect module instead. |
| 58 |
> |
| 59 |
|
| 60 |
It's been my opinion from the beginning that not allowing modules to be |
| 61 |
distributed outside of eselect limits its flexibility. However, I've kept my |
| 62 |
foot down to this point soley for QA reasons. It'd be a nightmare to keep |
| 63 |
track of the modules if they were all over the tree in various packages' files/ |
| 64 |
directories. |
| 65 |
|
| 66 |
After thinking about this a bit and reading the other responses you've gotten |
| 67 |
so far, I think we should keep all the modules in the main subversion |
| 68 |
repository and allow the modules to be distributed separately (once we have a |
| 69 |
stable API of course). |
| 70 |
|
| 71 |
Yay or nay on this? |
| 72 |
|
| 73 |
-- |
| 74 |
"Summer is butter on your chin and corn mush between every tooth." -Calvin |
| 75 |
|
| 76 |
Aaron Walker <ka0ttic@g.o> |
| 77 |
[ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ] |
| 78 |
|
| 79 |
-- |
| 80 |
gentoo-dev@g.o mailing list |
Archives