zdaemon-suffix

[Gediminas Paulauskas]

2011/4/27 Arnaud Fontaine <arnau at debian.org>:
> Hi,
>
> I'm  Cc'ing pkg-zope  because I  think it  could be  interesting  to get
> feedbacks from other maintainers as well.
>
>    > Hi  guys, I'm  the upstream for  http://bugs.debian.org/618936 and
>    >   found    it   very   interesting   that    Miguel   had   opened
>    > http://bugs.debian.org/623990 because it reminded me of an issue I
>    >  wasn't exactly sure  whom to  discuss with.   If you'd  prefer my
>    >  taking it  to  a tracker  of  some sort  instead  of mailing  you
>    > directly, just let me know.
>
> First of all, thanks for your email!
>
>    > The  question is,  why zdaemon  has to be  suffixed with  a string
>    > indicating which Python version it's intended to be used with. For
>    >  instance, when  one installs  zdaemon  using the  '# pip  install
>    > zdaemon' command, the  user-facing command is appropriately enough
>    >  called   'zdaemon'  whereas  using   a  DEB  means  one   gets  a
>    > 'zdaemon-2.6'  even though there's nothing  Python 2.6-specific to
>    > it. Same will go for  Python 2.7 and 'zdaemon-2.7' I guess but I'm
>    >  still using  Python  2.6.  There wouldn't  have  really been  any
>    >  pressing  issue with  it  hadn't I  been  starting  zdaemon in  a
>    > subprocess. So as long as people install sec-wall using pip I know
>    > the name of the command but as soon as a DEB is being used my code
>    > fails  horribly for obvious reasons.  Now, the fix  is probably to
>    > have  my code work around  it, I don't know,  that's probably what
>    > I'll end up doing.  It's just that I'm curious about the rationale
>    > behind renaming the otherwise working fine command for no apparent
>    > reason. Or rather, the  reason is probably there and has something
>    > to do  with the greater plan of how  Python command-line tools are
>    > being handled in Debian, it's just that I'm not aware of it :-)

In short, I agree. And have a fix below.

> AFAIK, this  is up  to the maintainer  of the  Debian package and  not a
> policy.   Personally, I  think it  makes  more sense  to have  versioned
> scripts  in  /usr/bin  or  /usr/sbin  for the  following  reasons  (when
> relevant  of course, because  as explained  below, when  the application
> supports  only one  version of  Python, there  is no  need  of versioned
> script):
>
> * All  the  language  interpreted   scripts  in  these  directories  are
>  generally  (always?)    expected  to  be   called  without  specifying
>  explicitely  the  interpreter to  be  used  on  the command  line,  so
>  following  the same  behavior  as  a compiled  binary  (which is  more
>  consistent IMHO).
>
> * As of  Python, if only one  non-versioned script is  provided in these
>  directories, but the script relies on modules supporting both Python 2
>  and 3, the  code of the script itself might differ,  thus ending up in
>  versioned scripts anyway,  namely one for Python 2  and one for Python
>  3.
>
>
> For zdaemon specifically,  there are only versioned scripts,  but as you
> explained, it might not be a  good idea neither to have *only* versioned
> scripts for  third-party applications. Therefore, perhaps  we could have
> the following:
>
> * Provides versioned  scripts only and only if  the application supports
>  multiple versions of Python.
>
> * The  non-versioned script  will  be  a link  to  the versioned  script
>  corresponding  to  the  default   Python  version.   In  case  of  the
>  application  does  not  support   multiple  versions  of  Python,  the
>  non-versioned script relies on the supported Python version.

If there are both zope-testrunner2.7 and zope-testrunner2.6 scripts,
and zope-testrunner is a link to zope-testrunner2.7, then you would
have both versioned and unversioned scripts. Better if there is a
zope-testrunner script that uses /usr/bin/python, e.g. paster from
python-pastescript. But then there is a problem if a new python
version is added or removed, the package needs to be rebuilt. In
Ubuntu Natty, I have paster and paster2.6 scripts, but not paster2.7.

Also, dh adds all to Depends: python, python2.6, python2.7

>
>
> This  is just my  opinion though,  therefore I  may miss  some important
> points. Let's see what others maintainers think about that...

I have removed the making of versioned scripts in zdaemon Ubuntu package:
https://launchpad.net/ubuntu/oneiric/+source/zdaemon/2.0.4-4ubuntu1

Other packages that had a similar rule have had it removed before
natty release (zope.testing, zodb, zc.buildout).

-- 
Gediminas Paulauskas