Status of jed-extra
G. Milde
g.milde at web.de
Tue Oct 4 10:33:38 UTC 2005
On 30.09.05, Rafael Laboissiere wrote:
> * G. Milde <g.milde at web.de> [2005-09-29 16:31]:
>
> > 3. Install a choice of modes (inclusive adding autoloads and
> > add_completion())
> > b) choosen from a list with debconf
> Agreed. Noticed that debconf is for site-wide configuration, so
> draconian choices made by root are imposed on the users.
...
> Another issue is about abusing debconf. Normally, debconf questions
> should be restricted to only the essential configuration options in the
> system. I think that the default answer is "install everything" and the
> priority of the question should be set to "low".
Considering the abuse issue and the workload implied (including my ignorance
of debconf programming), I propose a debconf-less alternative:
d) "minimal-invasive" activation in jed.d/20jed-extra.sl
* Categorize modes regarding their "invasiveness" (see Categorization_)
* Activate "non obstructing" modes
* Add comments for activating the other categories
* Describe the activation/configuration in README.debian
* Provide an example jed.rc for user configuration
+ 20jed-extra.sl is a config file, so the admin can override our
choice.
+ Prepared configuration options for categories make configuration
a bit more user friendly
- no GUI
> > Contained modes
> > ---------------
> >
> > Instead of just a download of Jedmodes-CVS, we should offer an
> > "intelligent" choice of packages: purge obsolete packages and add
> > interesting new ones ...
> Since you are the responsible person for jedmodes, I will let the choice
> of packages entirely in your hands.
We need to agree on a general policy:
Should the choice be
* "inclusive" (as much as sensible)
+ unified comprehensive package of jed modes
- more maintenance work (bugfixes, testing, ...)
- more impact on jed (possible slowdown of evalfile() and the like
due to more files in the jed search path [1]_)
* "selective" (as few as sensible, excluding "exotic" modes)
+ less work, less impact
- less value
.. _[1] Can be avoided, if "exotic" modes go to /usr/lib/jed-extra/archive
which is not added to the search path by default.
> Now, should we start the implementation of the new jed-extra along the
> ideas sketched above? I will really love to see jed 99.17-111 and the
> new jed-extra entering unstable soon.
We should. My ideas are described in more detail in
pkg-jed/trunk/packages/jed-extra/debian/README.Maintainer. This is meant
to be a collaborative document, so feel free to add/change stuff.
I am still unsecure about the right way to get the upstream sources. I
expect more issues to come up during the work on jed-extra that are best
solved upstream, so relying on a Sourceforge release seems not wise.
Guenter
--
G.Milde web.de
More information about the Pkg-jed-devel
mailing list