control: owner -1 ! Hello again Ben, Thank you for your response to my previous review. On Wed, Dec 07, 2016 at 08:06:36PM +0000, Ben Albrecht wrote: > >5. The UTF-8 decoder needs to be packaged separately -- Debian strongly > >discourages convenience copies of code. It might already be packaged > >for Debian, or you might have to prepare another RFS. > > I have not made any changes in response to this feedback. > > After discussing with others in the #debian-mentors channel, I don't > think packaging this separately is necessary. > > UTF-8 Decoder is a 42 line header file, which requires modifications to use for > Chapel specifically. Modifications include renaming and static prefixes to > avoid collisions. > > See https://codesearch.debian.net/search?q=bjoern.hoehrmann.de for a list > of existing packages that include UTF-8 decoder in their package. Okay. You're probably right, but I need to think some more about this to convince myself. In the meantime let's try to resolve the FHS issues, which are more pressing. Thank you for the additional info. > >7. The package is not compliant with the FHS. Almost everything is > >installed into /usr/lib/chapel, plus a symlink from /usr/bin/chpl into > >/usr/lib/chapel (only to the 64-bit version?). The main executable > >needs to be installed into /usr/bin/chpl. Please take a look at Debian > >policy section 9.1.1 and install the files appropriately. > > I have not made any changes in response to this feedback. > > The 'chpl' binary expects to live in $CHPL_HOME, and depends on > the contents of $CHPL_HOME/lib, $CHPL_HOME/make, $CHPL_HOME/modules, and > $CHPL_HOME/util. Therefore, I install this $CHPL_HOME directory as > /usr/lib/chapel, with the 'chpl' binary in $CHPL_HOME/bin/, so that it can > identify $CHPL_HOME without setting an environment variable. I read the 9.1.1 > documentation on the FHS, and still am not sure if /usr/lib or /usr/share is > the right place for $CHPL_HOME. > > Any guidance on this would be much appreciated. The basic distinction is that /usr/share is for arch-independent files, /usr/lib for arch-dependent files or a mix of arch-independent and arch-dependent if necessary. The CHPL_HOME problem ought to be fixed by patching chapel to look in different places for these different resources. For example, you can have it look in /usr/share/chapel for the modules/ subdir. Is there something about chapel's design that makes this difficult? You are installing lots of *.h, *.c and *.py files into /usr/lib/chapel. What is the purpose of this? How is the C source code necessary for compiling chapel programs? *.h files are supposed to be in /usr/include/ ... again, could you explain how they are necessary for compiling chapel programs? It looks like the *.py files are for a utility called 'chplenv'. Why not byte-compile the python code and install that into /usr/bin, with dh_python, in the usual way? It does not make sense to install it in such a way that only chapel-minimal is able to use it. The documentation is certainly installed into the wrong place. See dh_installdocs(1). > >11. I'm not an expert on multi-arch issues but this package seems to be > >targeted only at 32-bit and 64-bit Linux machines, just from looking at > >the 'linux32' and 'linux64' directories you have a lot of. Debian > >supports lots of other architectures, and the package should work on > >those. Is that something that can be fixed? > > I have not made any changes in response to this feedback. > > This is a way in which Chapel distinguishes platforms, which are independent > of the architectures Debian distinguishes. I would expect all Debian-supported > architectures to be categorized as either 'linux32' or 'linux64' platforms > for Chapel's purposes. > For a list of our platforms, see our documentation: > > http://chapel.cray.com/docs/1.14/usingchapel/chplenv.html#chpl-host-platform It seems that things have changed since we last spoke. I built the package and I now get paths like this: /usr/lib/chapel/runtime/src/threads/pthreads/gen/linux64.gnu.arch-native.loc-flat.comm-none.tasks-fifo.tmr-generic.unwind-none.mem-cstdlib.atomics-intrinsics.gmp-none.hwloc-none.re-none.wide-struct.fs-none/ According to the docs you linked to, a value of CHPL_HOST_PLATFORM is meant to be much shorter than this ... or am I misunderstanding? -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature