zdaemon-suffix

[Arnaud Fontaine]

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 :-)

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.


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

Cheers,
--
Arnaud Fontaine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-zope-developers/attachments/20110427/00a4b23d/attachment.pgp>