Re: [gentoo-dev] eselect modules

2005-09-04 Thread Bjarke Istrup Pedersen
-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



Re: [gentoo-dev] eselect modules

2005-08-17 Thread Aaron Walker

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 [EMAIL PROTECTED]
[ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ]

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] eselect modules

2005-08-16 Thread Jeremy Huddleston
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.



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] eselect modules

2005-08-16 Thread Donnie Berkholz

-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



Re: [gentoo-dev] eselect modules

2005-08-16 Thread Chris Gianelloni
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


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] eselect modules

2005-08-16 Thread Ciaran McCreesh
On Tue, 16 Aug 2005 15:38:08 -0400 Chris Gianelloni
[EMAIL PROTECTED] 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



pgp57cnfewKex.pgp
Description: PGP signature


Re: [gentoo-dev] eselect modules

2005-08-16 Thread Ciaran McCreesh
On Tue, 16 Aug 2005 21:52:25 +0200 Danny van Dyk [EMAIL PROTECTED]
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



pgpHsPftqAxYu.pgp
Description: PGP signature