[Mailman-Developers] [PATCH] Modifying #! env python line to match --with-python

[Ben Gertzfield]

>>>>> "BAW" == Barry A Warsaw <barry@zope.com> writes:
>>>>> "BG" == Ben Gertzfield <che@debian.org> writes:

    BG> You can't edit $path for every user possible who will run
    BG> anything mailman related..  This patch is pretty necessary.

    BAW> How many people do you expect to be using the command line
    BAW> interface for Mailman?

Every admin who needs to add a list, and every CGI script that needs
to do list maintainance.  Also, the build process runs lots of command
line scripts, which fail if python is not called python.

Basically, it's a huge hack for every Debian user to have to make a
/usr/local/bin/mailman script and set $path just for mailman.. I think
this is not the right solution.

    BAW> I know it's easy to change those files, but what I don't want
    BAW> to do is lose the CVS history of the files.  If CVS had a
    BAW> "move" or "copy" command, we'd be fine.  If I could hack
    BAW> directly on the repository myself, we'd be fine.  Otherwise,
    BAW> it's just too much of a hassle (and too fragile) to preserve
    BAW> the history of the files /and/ try to instruct the SF admins
    BAW> on the necessary repository surgery.

Here's an alternate solution, then.

We'll keep the files with their current names, but change 
#! /usr/bin/env python to #!/usr/bin/env @PYTHON@.  Then, instead of
using bin/script.in to create bin/script, we'll use the following
autoconf feature:

Create an empty build directory, say, build/bin/, and call AC_OUTPUT
like this.

AC_OUTPUT(build/bin/script:bin/script, build/foo/bar:foo/bar)

et cetera.  That way, we can keep the old names for the scripts, as
well as their CVS logs, but we just output the macro-expanded versions
under a directory tree that starts with build/ .

Is that a good enough solution?  I'm extremely interested in getting
this to work.  I can send a much smaller patch that implements this,
if you'd like.
    
    BAW> Also, from what I understand, now that Python's licensing
    BAW> problems are all cleared up, Debian plans to make Python
    BAW> 2.1.1 the default.

This may be, but a lot of people need Python 2.x on existing
distributions; in order to do that, python2 must co-exist with
python.  I really think the above solution is the happy medium;
nobody needs to know weird .in names, and the CVS logs are safe.

Please let me know what you think.

Ben

-- 
Brought to you by the letters X and R and the number 1.
"You should be glad you don't have diaper rash. Mah Jongg."
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/