Bug#833193: chapel/1.15 [ITP]
Hi Sean,
> Dear Ben,
>
> Thank you again for this well-organised response.
>
> To return the favour, in this e-mail I'll
>
> * discuss some logistics around this RFS;
> * raise an issue with the current source package on mentors;
> * respond to the substantive packaging topics in your e-mail.
>
> Logistics
> ---------
>
> (1) Can you confirm that [1] is the repository from which you generated
> the .dsc that you uploaded to mentors.debian.net? Can we work out of
> that repository from now on?
Yes.
> I want to be able to refer to git commits, and use `git diff` to review
> changes you've made in response to feedback. Using raw source packages
> is a pain.
>
> (2) It looks like we're going to need to package lots of library
> dependencies of the full chapel-runtime. I'm not going to be able to
> review and sponsor those -- it's too much for one volunteer. I will
> continue as the reviewer and eventual sponsor of the chapel source
> package itself (i.e. this RFS).
OK, thanks for letting us know. We'll seek other sponsors whenever
we start to pursue the other packages.
> Current source package
> ----------------------
>
> It fails to build, I think because it assumes $HOME exists, which is an
> assumption package builds cannot make (let me apologise that this is not
> better documented).
>
> I've attached a log.
We'll have a look. We're planning to patch `make check` to use /tmp
instead of $HOME for the Debian package.
> Responses to substantive packaging issues
> -----------------------------------------
>
> > Do you feel that we have addressed your concerns about the FHS?
>
> I think so! Three remaining issues:
>
> (1) Thank you for the explanation of the *.c, *.a, *.h files. Could you
> say what the *.py files are for? Again just part of the compilation
> process? Never expected to be run outside of that process?
The .py files are used to manage the Chapel configuration. The compiler
uses these scripts in order to determine the appropriate settings,
to include things like which tasking layer to use.
There is a utility, printchplenv, that prints out the current configuration.
However this tool is only really useful for people using a Chapel source
distribution.
For a binary distribution like we will have with Debian, we do not expect
users to run any of these scripts themselves. Only the `chpl` compiler
will run them.
> (2) Per Lumin, you're going to need to encode a version in the binary
> package names so that they can be co-installable. Further, in order
> that they can co-exist in the archive, you'll need to encode a version
> in the source package name, too.
OK, we're working on it (see PR #11 on our github repo). We're planning
to rename the source package to chapel-1.15.
> (3) I'll need to review the full list of installed files once you've
> finished implementing what you've described.
We'll let you know when we have the next version ready.
> Could you say more about why we want these other configurations?
>
> Imagine we upload chapel-minimal to Debian. Then later we upload the
> full build, including the qthreads support. Would anyone want to
> install chapel-minimal at that point?
>
> If you are thinking that chapel-minimal is a holdover because we foresee
> very long delays in bringing the Debian packages of the third-party
> dependencies into compatibility (see below), why not just have a chapel
> package that gradually gains functionality? Are you thinking that this
> might confuse users or break their build systems?
Yes, we expect it will take a long time to get all of the third-party stuff
packaged appropriately and we might not pursue that right away.
We're on board with a strategy of gradually bringing in the third-party support
- so we will rename chpl-compiler-minimal-1.15 and chapel-runtime-minimal-1.15
to just chapel-compiler-1.15 and chapel-runtime-1.15.
> > [...]
> > How should we handle the third-party dependencies as we expand beyond
> > just chapel-minimal?
>
> The chapel source package cannot build its own versions of third-party
> library dependencies. They need to be packaged separately.
>
> The relevant section of Debian policy is 4.13, but that doesn't
> sufficiently emphasise the security implications. Our security team
> requires that there is only one copy of a codebase in Debian, so they
> have to patch security bugs in only one place.
>
> Suppose the chapel source package builds a copy of the codebase. Then
> later, someone else wants to package another piece of software that uses
> the same library. In order to avoid two copies in the archive, they
> must now file a bug asking you to extract the codebase from chapel and
> put it in its own source package. This work now blocks that other
> packager. To avoid this unpleasant situation, we require packaging all
> dependencies separately in the first place.
>
> In the cases where chapel uses a non-standard configuration of a
> library, there are options other than modifying chapel. The relevant
> libraries can add new binary packages that install a copy of the library
> with the required configuration. This is at the discretion of the
> maintainers of those packages; you would need to make the case to them.
>
> In the cases where you've patched the upstream source of a library for
> functionality and/or performance, you can ask the maintainers of the
> relevant Debian packages to include those patches in Debian.
>
> I realise that this must seem dispiriting. I would completely
> understand if you decided that you do not have the time for all the work
> required to get the dependencies in good shape, and we upload only the
> minimal configuration to Debian. I hope you can understand that proper
> security support is a very high priority for us.
OK, for now we will only pursue a minimal version and leave
packaging the other third-party dependencies as future work.
Thanks,
Ben
Reply to: