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!
