jed-common (1:0.99.20~pre.170+dfsg-2) unstable; urgency=medium

    The mechanism for the install-time byte-compilation of *.sl files
    implemented in version 0.99.20~pre.167+dfsg-2 of the package works
    fine, but the generated files (*.slc for instance) are left behind
    when the associated package is removed.

    This problem is fixed now. The postinst script for jed and xjed will
    remove all generated files under the directory /usr/share/jed, before
    compiling them. This happens when files are either installed in or
    removed from /usr/share/jed and its descending sub-directories by
    dpkg.

    This is a brute-force, sub-optimal solution for a problem detected by
    piuparts. In the future, a mechanism for doing compilation of the *.sl
    files only when needed (i.s. only if the .sl file is newer than the
    corresponding .slc file) should be implemented. At any rate, for now,
    the processing time for recompiling all the *.sl files seems to be
    acceptable.

 -- Rafael Laboissière <rafael@debian.org>  Tue, 13 Dec 2022 09:26:29 -0300

jed-common (1:0.99.20~pre.167+dfsg-2) unstable; urgency=medium

    The mechanism for the install-time byte-compilation of *.sl files is
    changed in this version of the package. Previously, this was done in
    the postinst script of jed-common, by calling run-parts on the
    /usr/share/jed/compile/ directory. The executable files found in this
    directory are expected to install/remove scripts for
    generating/removing the *.slc files (compiled from the *.sl files).
    For now, only the jed-common and the jed-extra packages install
    scripts in this directory.

    The problem with this mechanism is that jed-extra had also to run its
    own script (/usr/share/jed/compile/jed-extra) in its postinst script.
    Even worse, the dependency relationships between jed, xjed,
    jed-common, and jed-extra could produce undesirable effects, like the
    one reported in Bug#563630[*]: when installation of jed-extra is
    required for installation in a system that lacks either jed or xjed,
    then a race condition will happen. Indeed, the postinst script for
    jed-common will be run before the postinst script for jed (or xjed),
    but the former needs the existence of /usr/bin/jed-script, which is
    created by the update-alternative call in the postinst script of
    the later.

    In order to fix this problem, we introduce the dpkg triggers
    mechanism in the current version. With this change,
    byte-compilation of *.sl is done by the postinst scripts of both
    jed and xjed, whose debian/*.trigger files declare an interest in the
    /usr/share/jed/compile/ directory. Also, the relationship
    "Recommends: jed|xjed" has been dropped for jed-common.

    The jed-extra package will be changed accordingly.

    [*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563630

 -- Rafael Laboissière <rafael@debian.org>  Fri, 29 Jul 2022 13:34:39 -0300

jed-common (1:0.99.19~pre89-1) experimental; urgency=medium

    The require function was dropped from site.sl and replaced by the require
    function in the package slsh. This function has a different argument list.
    The second (optional) argument accepted by the old jed version is the
    namespace for the file not the file name.

 -- Jörg Sommer <joerg@alea.gnuu.de>  Sat, 9 Jun 2007 23:34:41 +0200

jed-common (0.99.18+dfsg.1-1) unstable; urgency=low

    The handling of "~" in path names changed between version 0.99.16 of
    JED (the version in sarge) and 0.99.18.  This is an intended feature.
    According to the upstream author, John E. Davis: "evalfile is slang's
    lowest level file loading function, and as such it should not tamper
    with the name passed to it. For example, under Unix ~ is a perfectly
    valid directory name and it should be possible to load a file in that
    directory.  For filename expansion, use the expand_filename function.
    While not as convenient, [one] can also use evalfile("$HOME/foo.sl"$);"

 -- Rafael Laboissiere <rafael@debian.org>  Sun, 15 Apr 2007 11:09:21 +0200

jed-common (0.99.18-8) unstable; urgency=low

    Since release 0.99.17.135-1 of the package, the JED run-time
    configuration files are put in /etc/jed.d/ instead of
    /etc/jed-init.d/.  Due to a bug in dpkg (#108587) the config files
    00site.sl, 00debian.sl and 99defaults.sl as well as /etc/jed.conf are
    not removed after an upgrade to 0.99.15-1 or higher.

    A debconf question has been added to the jed-common package to inform
    the user if modified files are kept in /etc/jed-init.d/. However, the
    script that was responsible for deleting the files was defective and
    there may be cases where the files are still in the system but shouldn't
    be. (The debconf question can be revisited by running "dpkg-reconfigure
    jed-common".)

    The directory /etc/jed-init.d/ is no longer needed and should be removed
    after transferring eventual customizations to /etc/jed.d/.

 -- Rafael Laboissiere <rafael@debian.org>  Sat, 28 Jul 2007 00:35:50 +0200

jed-common (0.99.18-7) unstable; urgency=low

    Important changes in the start-up scheme have been introduced in this
    version. Users upgrading from sarge should read the file
    /usr/share/doc/jed-common/README.Debian-sarge-upgrade

 -- Rafael Laboissiere <rafael@debian.org>  Thu, 21 Jun 2007 12:15:36 +0200
