Required packages for gdbmrecent
Rafael Laboissiere
rafael at debian.org
Tue Feb 6 17:20:40 CET 2007
* 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
More information about the Pkg-jed-devel
mailing list