zdaemon-suffix
Arnaud Fontaine
arnau at debian.org
Wed Apr 27 13:55:56 UTC 2011
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>
More information about the pkg-zope-developers
mailing list