Required packages for gdbmrecent

[Rafael Laboissiere]

* G. Milde <g.milde at quantentunnel.de> [2007-02-06 15:14]:

> On  6.02.07, Rafael Laboissiere wrote:
> >     * Depends: jed-extra (>= 2.2.1-1.etch.2), slang-gdbm
> 
> We could have a jed-extra 2.2.1-2 with the gdbmrecent patch, no need for an
> "etch" forge. (But you could also keep this if it is easier.)

jed-extra 2.2.1-2, which was uploaded to experimental, contained the debconf
templates for removing the old files in /etc/jed-init.d/.  This would be a
big change to get into testing.  Keeping the etch branch in unstable is a
good thing, I think, because the etch release is taking longer than expected
and this is the easiest way to get RC bugs fixed.

> I reintroduced them, as they do no harm and are fine for people using
> gdbmrecent with "manual" activation instead of installing jedstates.

Oh, I just reverted them in 2.2.1-3.  Please, feel free to put them back.

> You forgot to change the package description -- Please have a look at my
> changes, as I am not sure whether I got everything correct. 

I did minor changes before uploading.  Thanks!

> Also, are you sure that gdbmrecent.sl has *all* functionality of
> jedstate (so that it really "supersedes" jedstates) or just a subset?
> Maybe we could choose a more cautious wording in the description.

Actually, gdbmrecent is a superset of jedstate.  The later could only store
the cursor position of visited files, while the former can also store buffer
local variables (like Ispell dictionaries).  This is a handy feature.

There was one thing though that jedstate had and that is lacking in
gdbmrecent: the /usr/bin/jedstate command could be used to purge old entries
in the database, without having to call jed.  I will add a Perl script to do
this in the jedstate transitional package.

-- 
Rafael