Processed: Re: Bug#482487: jed-extra: pcre.sl does not exist

[G. Milde]

On 17.06.08, Jörg Sommer wrote:
> G. Milde schrieb am Tue 17. Jun, 10:23 (+0200):
> > On 16.06.08, Debian Bug Tracking System wrote:
> > 
> > > > reassign 482487 jed-common
> > > Bug#482487: jed-extra: pcre.sl does not exist
> > > Bug reassigned from package `slsh,jed-common' to `jed-common'.
> > 
> > Please leave this bug assigned to slsh as well: the documentation says:
> > 
> >   assign to two packages only, if it can be solved by either of them.
> >   
> > slsh can solve the bug by re-introducing a directory

> For me this is not a solution but a workaround. I don't want to force
> slsh to ship an empty directory to make jed work. This sounds scary.

What shall we do with Johns response 
<200804141645.m3EGjSnM032695 at aluche.mit.edu> then?

   On 14.04.08, John E. Davis wrote:
   
   > On my Debian etch system there is a directory called
   > /usr/lib/python2.4/site-packages, which serves the same purpose as
   > slsh's local-packages directory.  In fact, the README file in that
   > directory contains
   
   >   This directory exists so that 3rd party packages can be installed
   >   here.  Read the source for site.py for more details.
   
   > Are such directories allowed under /usr/lib but not under /usr/share?
   > Thanks,
   > --John

File a new bug to slsh?

> > > > retitle 482487 jed-common: Respect /u/s/slsh even if /u/s/slsh/local is missing
> > > Bug#482487: jed-extra: pcre.sl does not exist
> > > Changed Bug title to `jed-common: Respect /u/s/slsh even if /u/s/slsh/local is missing' from `jed-extra: pcre.sl does not exist'.
> > 
> > Please use full written path names in public visible places to avoid
> > ambiguity and be understandable to non-experts.

> The title is the text used in the subject of the report mail and e‐mail
> subjects should not exceed 80 characters.

So, how about 

jed-common: Make sure /usr/share/slsh is in the jed library path

? Remember that the bug database is frequently browsed by frustrated
users that want to find out why their program fails to work as expected.
Giving indicative labels to bugs also hepls prevent duplicate reports.

Günter