Bug#833193: chapel/1.15 [ITP]

[Sean Whitton]

control: noowner -1

Dear Ben,

On Wed, May 24 2017, Sean Whitton wrote:

> I will continue as the reviewer and eventual sponsor of the chapel
> source package itself (i.e. this RFS).

Unfortunately, I'm going to have to renege on this.  I recently got a
new job within Debian, and the new semester is starting.  I wish you the
best of luck and hope that chapel is able to make its way into Debian
soon.  I hope my comments were helpful to that process.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833193: chapel/1.15 [ITP]

[Ben Albrecht]

Hi Sean,

We have made the updates requested in the following PRs:

https://github.com/chapel-lang/chapel-packaging/pull/11

https://github.com/chapel-lang/chapel-packaging/pull/13


Thanks,

Ben


On 5/26/17, 6:42 AM, "Sean Whitton"  wrote:

Hello Ben,

On Thu, May 25, 2017 at 08:11:30PM +, Ben Albrecht wrote:
> We'll let you know when we have the next version ready.

Okay.  To do this, you can just remove the 'moreinfo' tag from this RFS
bug.

> OK, for now we will only pursue a minimal version and leave
> packaging the other third-party dependencies as future work.

It would be good to document this in debian/README.source inside the
package.  You could put the table you wrote up in that file.  That way,
other Debian contributors who are interested in chapel could get
involved with getting the dependencies in shape.

-- 
Sean Whitton

Bug#833193: chapel/1.15 [ITP]

[Sean Whitton]

Hello Ben,

On Thu, May 25, 2017 at 08:11:30PM +, Ben Albrecht wrote:
> We'll let you know when we have the next version ready.

Okay.  To do this, you can just remove the 'moreinfo' tag from this RFS
bug.

> OK, for now we will only pursue a minimal version and leave
> packaging the other third-party dependencies as future work.

It would be good to document this in debian/README.source inside the
package.  You could put the table you wrote up in that file.  That way,
other Debian contributors who are interested in chapel could get
involved with getting the dependencies in shape.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833193: chapel/1.15 [ITP]

[Ben Albrecht]

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