[Pkg-jed-commit] r59 - in trunk/packages/jed/debian: . init.d patches

[Jörg Sommer]

Hallo G.,

G. Milde schrieb am Wed 14. Sep, 10:35 (+0200):
> On 11.09.05, Jörg Sommer wrote:
>  
> > * added 40_site.sl-startup.dpatch to make the startup go the Debian way,
> >   i.e. the files in /etc/jed.d/ get evaluated by jed, the
> >   Default_Jedrc_Startup_File is set to NULL, which was done in jed.conf
> >   before.
> 
> Why not keep this setting in jed-init.d/05jed-common.sl?

First I would name the directory as the package, second, yes it should
be jed-common.sl and third if we fix the startup in site.sl, we can fix
this there too. IIRC John said he will set this in a later version as
default.

> >   + added a function "register_libdir()", which *appends* a library dir
> >     to the corresponding variables. I think appending is better to make
> >     Jed behaves the same way before and after adding a new libdir (iow a
> >     new package is installed).
> 
> Appending will introduce incompatiblities.

Right.

> home-lib.sl has a function register_libdir() that *prepends* the path
> for a reason. Drop-in replacements (e.g. Jedmodes' (hyper)help.sl) and
> patched versions of standard library files should be found first by
> evalfile() and friends also if they are provided by a package or the
> sysadmin.

Indeed and I didn't find an aswer to this problem. But I did this
change, because I think installing a new package should not change the
behaviour of the package. And otherwise a new file 99home-jedrc.sl is
needed to prepend the ~/.jed/ after all packages have prepended their
dirs and if a package calls evalfile("foo") in its startup script this
file can't get replaced by the user or sysadmin. Therefore the home lib
must be in the path before all other packages add their directories and
these packages should not cover home lib.

> >   + it is also checked for ~/.jed and it is *prependened* in the
> >     variables if it exist
> 
> If we leave register_libdir() as in home-lib.sl, it could be used here,
> making the file a lot shorter.
> 
> IMHO, we should also register /usr/share/jed/site-lib/ so it is ready for
> other packages to put their modes in.

I'm against placing files of different packages in the same directory.
A new package should use (and register) a new directory to avoid name
collision. And think of the problem of the compile-remove script.

> A function definition should IMO not be in a config file. Setting up
> /usr/share/jed/site-lib/ in jed-common will enable us to write

A good question: Should jed-common ship more than what upstream provides?
Or more strictly should jed-common include files of other parties than
upstream and Debian?

> >   + now do not install jed.conf anymore and install the *.sl files in
> >     /etc/jed.d/
> 
> /etc/jed.d/README.Debian-startup needs to be updated to this change.
> (actually, this info should be in /u/s/doc/jed-common/README.debian.)

I thought about symlinking /e/j/RE... to /u/s/d/j/R... What do you think?

> > Added: trunk/packages/jed/debian/patches/40_site.sl-startup.dpatch
> > ===================================================================
> ...
> > ++if (BATCH != 2) {  % do not evaluate if jed is started as jed-script
> > ++    $1 = listdir("/etc/jed.d/");
> ...
> 
> While this test will solve the "build a new jed version" problem, it is
> IMHO not flexible enough.  What, if soemone wants to use jed-script with
> a function provided by e.g. jed-extra?

Yes, I know. But introducing a new commandline option needs heavy changes
on site.sl, because we must ignore this commandline option in
command_line_hook(). Did we get a decision of name of the command line option?

Bye, Jörg.
-- 
»Perl - the only language that looks the same
 before and after RSA encryption.«           -- Keith Bostic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-jed-devel/attachments/20050914/baf5a17c/attachment.pgp