Status of jed-extra

[G. Milde]

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