[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#833193: RFS: chapel/1.15-1 [ITP]



Hi Ben,

> We do install the Chapel modules and runtime to versioned directories
> like this:
>
>     /usr/share/chapel/1.15/modules etc
>
> The documentation is installed to
>
>      /usr/share/doc/chapel/1.15/rst etc
>
> Is it obviously better in your opinion to use
>
>      /usr/share/chapel-1.15/modules
>
> e.g.? If so, can you say why?

This way users will not be able to install 2 different versions of chapel
at the same time. For example, chapel/1.15 package will conflict
with chapel/1.16 on some standard files e.g.:

  /usr/share/doc/chapel/changelog.Debian.gz  (in chapel/1.15)
  /usr/share/doc/chapel/changelog.Debian.gz  (in chapel/1.16)

If you really plan to provide room for users to install multiple versions
at the same time, I'd suggest you change the binary package name
from chapel -> chapel-1.15 , this does not affect your

  /usr/share/chapel

directory. That is to say, you name the binary package as chapel-1.15
and the docs will be installed to /usr/share/doc/chapel-1.15
(/usr/share/doc/<binary-package-name>)
and (/usr/share/chapel) is controlled by yourself.


> The upstream project supports both Python 2.7 and Python 3.
> Would it be sufficient to depend on Python >= 2.7?
> I don't think it would make sense to update the scripts to
> have a Python 3 shebang (like #!/usr/bin/env python3).
> Do we assume that /usr/bin/env python returns a python 3 in
> some cases?

Debian's Python Policy:
https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html

A python2.7 package "python-*" may install files under this directory
/usr/lib/python2.7/xxx

while a Python3 package "python3-*" may install files under a
different directory
/usr/lib/python3/xxx

This does not require changing the first line of python code. My point is
that providing another package that supports python3 and install stuff to
one of python3's search path.


Thank you for working on it!


Reply to: