* Re: [gentoo-dev] eselect modules
2005-08-16 19:07 ` [gentoo-dev] eselect modules Jeremy Huddleston
@ 2005-08-16 19:21 ` Donnie Berkholz
2005-08-16 19:38 ` Chris Gianelloni
2005-08-16 19:52 ` Danny van Dyk
` (2 subsequent siblings)
3 siblings, 1 reply; 17+ messages in thread
From: Donnie Berkholz @ 2005-08-16 19:21 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeremy Huddleston wrote:
| The eselect developers want to keep all eselect modules in their svn
| repository and distributed through a single package (app-admin/eselect).
| Their main reasons for this are better QA and less overhead for releases
| and merging.
And unnecessarily tying releases together of things that have no reason
to be tied together.
It's fine to keep all the source in the same repository, but don't lock
releases of unrelated modules together. That's the same thing X went
through and has finally learned with the modularization effort.
Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDAjzGXVaO67S1rtsRAt/jAKC5iEbkyTvqTAm44EB1PVur7wqDiwCcC/HD
umiI6mrs67f+YBVxDAJz/0U=
=yK5P
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [gentoo-dev] eselect modules
2005-08-16 19:21 ` Donnie Berkholz
@ 2005-08-16 19:38 ` Chris Gianelloni
2005-08-16 19:49 ` Ciaran McCreesh
0 siblings, 1 reply; 17+ messages in thread
From: Chris Gianelloni @ 2005-08-16 19:38 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
On Tue, 2005-08-16 at 12:21 -0700, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jeremy Huddleston wrote:
> | The eselect developers want to keep all eselect modules in their svn
> | repository and distributed through a single package (app-admin/eselect).
> | Their main reasons for this are better QA and less overhead for releases
> | and merging.
>
> And unnecessarily tying releases together of things that have no reason
> to be tied together.
>
> It's fine to keep all the source in the same repository, but don't lock
> releases of unrelated modules together. That's the same thing X went
> through and has finally learned with the modularization effort.
There's also the size issue. I use opengl-update on the LiveCD builds,
and have exactly zero need for *any* other eselect module, so why should
I be required to have them all to just get the one that I need?
--
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] eselect modules
2005-08-16 19:38 ` Chris Gianelloni
@ 2005-08-16 19:49 ` Ciaran McCreesh
0 siblings, 0 replies; 17+ messages in thread
From: Ciaran McCreesh @ 2005-08-16 19:49 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
On Tue, 16 Aug 2005 15:38:08 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| There's also the size issue. I use opengl-update on the LiveCD
| builds, and have exactly zero need for *any* other eselect module, so
| why should I be required to have them all to just get the one that I
| need?
Heh. You complain about the size of an eselect module, and then go and
include a stinkin' great bitmap splash screen.
Anyway, I'm in favour of separate distribution of modules once eselect
reaches a 1.0 release. Until then there's still a chance someone might
go and change the API...
--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] eselect modules
2005-08-16 19:07 ` [gentoo-dev] eselect modules Jeremy Huddleston
2005-08-16 19:21 ` Donnie Berkholz
@ 2005-08-16 19:52 ` Danny van Dyk
2005-08-16 19:59 ` Ciaran McCreesh
2005-08-16 20:20 ` Jeremy Huddleston
2005-08-17 3:59 ` Aaron Walker
2005-09-04 18:22 ` Bjarke Istrup Pedersen
3 siblings, 2 replies; 17+ messages in thread
From: Danny van Dyk @ 2005-08-16 19:52 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Jeremy,
(Just a note: the follwing expresses my opinion, i don't speak for the
other eselect devs)
Jeremy Huddleston schrieb:
| I've recently updated opengl-update to use the eselect framework. I
| think the team has done a great job as it was extremely easy to port the
| bash script to an eselect module. However, when I placed it in the
:-)
| portage tree, it sparked a little bit of a policy discussion between
| myself and the core eselect devs on how to best include modules in the
| tree, so I'd like to let other devs chime in as well.
[snip]
| The eselect developers want to keep all eselect modules in their svn
| repository and distributed through a single package (app-admin/eselect).
| Their main reasons for this are better QA and less overhead for releases
| and merging.
My opinion is this: Keeping eselect modules inside eselect's SVN repo
results in:
a) More eyes reading the code (read: QA)
b) The possibility to change all modules in one move in case we change
~ something like a default behaviour, or function names, etc.
Having all modules in the same repository is imho more important than
having only one package to distribute it. I can happily live with
x11-base/opengl-update installing a module inside
~ /usr/share/eselect/modules
and creating a symlink for opengl-update.
| I have a problem with this policy because:
| 1) Stability of the modules should not be tied to stability of the core
| package. Basically, I'd like to determine when my modules get pushed
| into stable without considering how it'll effect the eselect modules of
| other developers. Similarly, I don't want bugs in another module
| holding up my module from going into stable.
Understandable.
| 2) Not all users will want all modules. The goal of the eselect project
| is to provide a framework to replace java-config, motif-config,
| gcc-config, binutils-config, opengl-update, etc, but not all users will
| need all modules.
I agree here as well...
| 3) Some modules require extra files (opengl-update installs header
| files, gcc-config installs a wrapper, etc), and the app-admin/eselect
| package is not the correct place to provide these files.
jupp...
| Also, what should the correct way to introduce these modules into
| portage?
| Should we keep them in the packages they're replacing
| (x11-base/opengl-update)?
| Should we place them in a new package in the same category as the script
| they're replacing (x11-base/eselect-opengl)?
| Should we place them in app-admin/eselect-<module name> or perhaps
| app-eselect/<module name>?
I'd prefer app-admin/eselect-<modulename>, but i could happily live with
app-eselect/<modulename>. But i don't think that we need a whole new
category for eselect modules. Not right now, and probably not in future,
either.
| Note that for backwards compatibility in all cases,
| x11-base/opengl-update will RDEPEND on this eselect module and install a
| backwards-compatible frontend to the eselect module until all packages
| in portage have been updated to use the eselect module instead.
Jeremy, do you know about the 'old-script-name' feature that Ciaran
introduced?
By symlinking /usr/bin/eselect to one of these
~ <module>-update, <module>-config, <module>-manager, config-<module>,
~ update-<module> or manage-<module>,
a call to it will be handles as if the user called 'eselect <module>'.
You might probably want to consider this for your opengl-update package.
app-admin/eselect currently installs these symlinks automatically:
~ kernel-config, profile-config, rc-config, bashcomp-config
Btw: Thx for you feedback on eselect. It really appreciated it :-)
Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDAkP4aVNL8NrtU6IRAhEkAJ9zqqfiaruWxy+PQ1e57ybNOcgWIgCff6Y8
q0TidAU1r1rlCb6uuAwRiMM=
=BY+s
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] eselect modules
2005-08-16 19:52 ` Danny van Dyk
@ 2005-08-16 19:59 ` Ciaran McCreesh
2005-08-16 20:20 ` Jeremy Huddleston
1 sibling, 0 replies; 17+ messages in thread
From: Ciaran McCreesh @ 2005-08-16 19:59 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
On Tue, 16 Aug 2005 21:52:25 +0200 Danny van Dyk <kugelfang@gentoo.org>
wrote:
| b) The possibility to change all modules in one move in case we change
| ~ something like a default behaviour, or function names, etc.
That kind of thing shouldn't happen once a stable release is out...
--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] eselect modules
2005-08-16 19:52 ` Danny van Dyk
2005-08-16 19:59 ` Ciaran McCreesh
@ 2005-08-16 20:20 ` Jeremy Huddleston
1 sibling, 0 replies; 17+ messages in thread
From: Jeremy Huddleston @ 2005-08-16 20:20 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]
> My opinion is this: Keeping eselect modules inside eselect's SVN repo
> results in:
> a) More eyes reading the code (read: QA)
I think the point you're trying to make here is that the QA is easier to
accomplish for you, and that certainly is true.
I think having modules in app-admin/eselect-<module>/files/ or in
> b) The possibility to change all modules in one move in case we change
> ~ something like a default behaviour, or function names, etc.
Well, this default behavior shouldn't change once 1.0 is finished, so I
think ciaranm's point is valid. Once 1.0 is released, the API should
stabilize, and you should let developers utilize this framework, but
until then, perhaps a little bit tighter control is prudent.
> Having all modules in the same repository is imho more important than
> having only one package to distribute it. I can happily live with
> x11-base/opengl-update installing a module inside
> ~ /usr/share/eselect/modules
> and creating a symlink for opengl-update.
Ok, then I can certainly live with this until 1.0 stabilizes (and
perhaps longer if the development model works well) as long as it's the
repository we're talking about and not the package or tarball (meaning
I'd like to bzip2 my eselect module from the repository and use that in
the package rather than getting it out of an eselect-<version> tarball).
> I'd prefer app-admin/eselect-<modulename>, but i could happily live with
> app-eselect/<modulename>. But i don't think that we need a whole new
> category for eselect modules. Not right now, and probably not in future,
> either.
Yeah, app-admin/eselect-<module name> seems reasonable.
> Jeremy, do you know about the 'old-script-name' feature that Ciaran
> introduced?
> By symlinking /usr/bin/eselect to one of these
>
> ~ <module>-update, <module>-config, <module>-manager, config-<module>,
> ~ update-<module> or manage-<module>,
>
> a call to it will be handles as if the user called 'eselect <module>'.
> You might probably want to consider this for your opengl-update package.
Actually, no I didn't, but I'll look into it later tonight.
Thanks,
Jeremy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] eselect modules
2005-08-16 19:07 ` [gentoo-dev] eselect modules Jeremy Huddleston
2005-08-16 19:21 ` Donnie Berkholz
2005-08-16 19:52 ` Danny van Dyk
@ 2005-08-17 3:59 ` Aaron Walker
2005-09-04 18:22 ` Bjarke Istrup Pedersen
3 siblings, 0 replies; 17+ messages in thread
From: Aaron Walker @ 2005-08-17 3:59 UTC (permalink / raw
To: gentoo-dev
Jeremy Huddleston wrote:
> I've recently updated opengl-update to use the eselect framework. I
> think the team has done a great job as it was extremely easy to port the
> bash script to an eselect module. However, when I placed it in the
> portage tree, it sparked a little bit of a policy discussion between
> myself and the core eselect devs on how to best include modules in the
> tree, so I'd like to let other devs chime in as well.
>
> Firstly if you don't know what eselect is, check out:
> http://www.gentoo.org/proj/en/eselect/index.xml
>
> The eselect developers want to keep all eselect modules in their svn
> repository and distributed through a single package (app-admin/eselect).
> Their main reasons for this are better QA and less overhead for releases
> and merging.
QA is my main concern.
>
> I have a problem with this policy because:
> 1) Stability of the modules should not be tied to stability of the core
> package. Basically, I'd like to determine when my modules get pushed
> into stable without considering how it'll effect the eselect modules of
> other developers. Similarly, I don't want bugs in another module
> holding up my module from going into stable.
agreed.
>
> 2) Not all users will want all modules. The goal of the eselect project
> is to provide a framework to replace java-config, motif-config,
> gcc-config, binutils-config, opengl-update, etc, but not all users will
> need all modules.
>
> 3) Some modules require extra files (opengl-update installs header
> files, gcc-config installs a wrapper, etc), and the app-admin/eselect
> package is not the correct place to provide these files.
agreed.
>
> Also, what should the correct way to introduce these modules into
> portage?
> Should we keep them in the packages they're replacing
> (x11-base/opengl-update)?
> Should we place them in a new package in the same category as the script
> they're replacing (x11-base/eselect-opengl)?
> Should we place them in app-admin/eselect-<module name> or perhaps
> app-eselect/<module name>?
Good question. I don't really have a preference.
>
> Note that for backwards compatibility in all cases,
> x11-base/opengl-update will RDEPEND on this eselect module and install a
> backwards-compatible frontend to the eselect module until all packages
> in portage have been updated to use the eselect module instead.
>
It's been my opinion from the beginning that not allowing modules to be
distributed outside of eselect limits its flexibility. However, I've kept my
foot down to this point soley for QA reasons. It'd be a nightmare to keep
track of the modules if they were all over the tree in various packages' files/
directories.
After thinking about this a bit and reading the other responses you've gotten
so far, I think we should keep all the modules in the main subversion
repository and allow the modules to be distributed separately (once we have a
stable API of course).
Yay or nay on this?
--
"Summer is butter on your chin and corn mush between every tooth." -Calvin
Aaron Walker <ka0ttic@gentoo.org>
[ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ]
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [gentoo-dev] eselect modules
2005-08-16 19:07 ` [gentoo-dev] eselect modules Jeremy Huddleston
` (2 preceding siblings ...)
2005-08-17 3:59 ` Aaron Walker
@ 2005-09-04 18:22 ` Bjarke Istrup Pedersen
2005-09-04 18:30 ` Stuart Herbert
2005-09-04 18:38 ` Ciaran McCreesh
3 siblings, 2 replies; 17+ messages in thread
From: Bjarke Istrup Pedersen @ 2005-09-04 18:22 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeremy Huddleston skrev:
> I've recently updated opengl-update to use the eselect framework. I
> think the team has done a great job as it was extremely easy to port the
> bash script to an eselect module. However, when I placed it in the
> portage tree, it sparked a little bit of a policy discussion between
> myself and the core eselect devs on how to best include modules in the
> tree, so I'd like to let other devs chime in as well.
>
> Firstly if you don't know what eselect is, check out:
> http://www.gentoo.org/proj/en/eselect/index.xml
>
> The eselect developers want to keep all eselect modules in their svn
> repository and distributed through a single package (app-admin/eselect).
> Their main reasons for this are better QA and less overhead for releases
> and merging.
>
> I have a problem with this policy because:
> 1) Stability of the modules should not be tied to stability of the core
> package. Basically, I'd like to determine when my modules get pushed
> into stable without considering how it'll effect the eselect modules of
> other developers. Similarly, I don't want bugs in another module
> holding up my module from going into stable.
>
> 2) Not all users will want all modules. The goal of the eselect project
> is to provide a framework to replace java-config, motif-config,
> gcc-config, binutils-config, opengl-update, etc, but not all users will
> need all modules.
>
> 3) Some modules require extra files (opengl-update installs header
> files, gcc-config installs a wrapper, etc), and the app-admin/eselect
> package is not the correct place to provide these files.
>
> Also, what should the correct way to introduce these modules into
> portage?
> Should we keep them in the packages they're replacing
> (x11-base/opengl-update)?
> Should we place them in a new package in the same category as the script
> they're replacing (x11-base/eselect-opengl)?
> Should we place them in app-admin/eselect-<module name> or perhaps
> app-eselect/<module name>?
>
> Note that for backwards compatibility in all cases,
> x11-base/opengl-update will RDEPEND on this eselect module and install a
> backwards-compatible frontend to the eselect module until all packages
> in portage have been updated to use the eselect module instead.
>
Any plans on moving webapp-config as an eselect module? :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDGzt+O+Ewtpi9rLERAiZgAKDAzrI29bEbUoVKdji4r9vaZOFFcwCdGbfo
rXlfU7yQb6qvpuMj2BR806Y=
=d86l
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [gentoo-dev] eselect modules
2005-09-04 18:22 ` Bjarke Istrup Pedersen
@ 2005-09-04 18:30 ` Stuart Herbert
2005-09-04 18:38 ` Ciaran McCreesh
1 sibling, 0 replies; 17+ messages in thread
From: Stuart Herbert @ 2005-09-04 18:30 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
On Sun, 2005-09-04 at 20:22 +0200, Bjarke Istrup Pedersen wrote:
> Any plans on moving webapp-config as an eselect module? :-)
No.
Best regards,
Stu
--
Stuart Herbert stuart@gentoo.org
Gentoo Developer http://www.gentoo.org/
http://stu.gnqs.org/diary/
GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
--
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [gentoo-dev] eselect modules
2005-09-04 18:22 ` Bjarke Istrup Pedersen
2005-09-04 18:30 ` Stuart Herbert
@ 2005-09-04 18:38 ` Ciaran McCreesh
1 sibling, 0 replies; 17+ messages in thread
From: Ciaran McCreesh @ 2005-09-04 18:38 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 393 bytes --]
On Sun, 04 Sep 2005 20:22:54 +0200 Bjarke Istrup Pedersen
<gurligebis@gentoo.org> wrote:
| Any plans on moving webapp-config as an eselect module? :-)
That one's way beyond the scope of what eselect was designed for.
--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread