Re: debian diffs for 2.7.0

>>>Alexander Zangerl said:
 > i'm (co)maintaining exmh for debian, and as such had to adjust certain aspec
     ts
 > of the package a little bit when i packaged 2.7. 
 > mostly it's small stuff like paths and such, but still some of those patches
      
 > may be useful for the upstream version, too, so here they are.
 > 
 > the attached files (wrapped in tar) are plain diffs with a bit of 
 > integration fluff in the first couple of lines (dpatch); 
 > i'll describe the contents briefly.
 > 
 > 01_changes_from_v2511.dpatch
 >  fix of an old pgp problem where recipients were duplicated when
 >  pgp is run in interactive mode
 > 	
 > 02_versions_and_pathes.dpatch
 >  path of wish, expect etc. is fully qualified on every 
 >  hashbang line. debian policy mandates this and i think it's a 
 >  good idea anyway.

This patch changes the exmh.MASTER files and other .MASTER files.
These are all templates used by the ordinary exmh.install process.
These files are never directly deployed, and so changing the pathname
in there doesn't do anything except mess up exmh.install.  The installer
re-writes these to begin with an absolute pathname.  There are also
changes in there to add this:
  source /etc/exmh.conf
which is also completely different than the normal exmh setup.

I won't be able to pick up the 02* patch for these reasons.  For
distribution-specific installs, I suggest you use the exmh.install
process to generate the target exmh, exmh-bg, exmh-async, ftp.expect,
and inc.expect scripts.  Then, take those generated files and put
them into your distributions.  You should not mess with the .MASTER
files directly.  The whole idea of those templates is that site-specific
settings are injected into those templates by exmh.install.  The
only place that should have any hard-wired paths is the block of
code in exmh (and the others) between the
#CONFIGURATION
#END CONFIGURATION
comments.  If you find yourself wiring pathnames anywhere else,
it is guaranteed to be wrong for someone else.

 >  help files are all moved away from the lib dir,
 >  the variable exmh(helploc) describes where that is
 >  (/usr/share/doc/exmh/html/ on debian)

I couldn't find the definition of exmh(helploc) anywhere, so I
can't take this part of the patch, either.  This is a fine idea,
but the right way to do it is add an entry to exmh.install to define
this.

 > 03_extpass_docfix.dpatch
 >  a small documentation improvement for the pgp(getextcmd) functionality.
 > 
 > 03_face_default.dpatch
 >  faces(xfaceProg) gains a default (uncompface -X)
 > 
 > 03_fix_bitmap_locations.dpatch
 >  the icon bitmaps move away from /usr/lib/exmh
 >  exmh(bitmaps) holds the location and all code uses that; 
 >  only bitmaps.default has the location hardcoded.
 >  (/usr/share/exmh/bitmaps on debian)
 > 
 >  it's bad form mixing up all kinds of content in /usr/lib/exmh, and debian
 >  policy mandates the code/shareable/local distinction. 

This will be ok, although it isn't right that this file has hardcoded
paths.  Obviously I don't use the bitmap resources much or I would have
noticed.  This is another thing that should be handled differently so
the path information is properly configurable and that the paths match
where things get installed by exmh.install.

 > 03_fix_multikeys.dpatch
 >  fix for http://bugs.debian.org/164210: multiple gpg subkeys and passphrases
     .
 >  exmh would not ask for the right passphrase.
 > 
 > 03_ldap_searches.dpatch
 >  ldap options gain defaults that are compatible with debian's openldap confi
     g
 >  
 > 03_scripts_in_usr_share.dpatch
 >  the non-user-callable scripts (exmh-bg, ftp.expect;  
 >  everything except the main exmh script) move from /usr/bin 
 >  into /usr/share/exmh.
 >  
 >  one more of those debian policy issues.

Again, I can't take this patch as-is because it hardcodes a pathname.
I have, however, made some changes so that ftp.expect and inc.expect
are executed from $install(dir,bin), which is the installation directory
for scripts.  If you look at the exmh script generated by exmh.install
you'll see that it defines this variable.

 > net result of those patches: /usr/lib/exmh holds only the tcl innards,
 > /usr/bin has only exmh itself, the mostly-internal scripts live in 
 > /usr/share/exmh and the bitmaps and docs are also no longer cluttering 
 > the library dir.

I don't mind this style of directory organization, but it needs to be
done in exmh.install first.

Thanks much for all the other pgp and ldap fixes, which I've picked up.

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
[email protected]