[Debian-science-sagemath] [sage-devel] Upcoming Debian freeze

[E. Madison Bray]

On Mon, Jan 7, 2019 at 5:35 PM Jerome BENOIT <calculus at rezozer.net> wrote:
>
>
>
> On 07/01/2019 19:33, E. Madison Bray wrote:
> > On Mon, Jan 7, 2019 at 4:20 PM Jerome BENOIT <calculus at rezozer.net> wrote:
> >>
> >> Hello,
> >>
> >> On 07/01/2019 18:07, E. Madison Bray wrote:
> >>> Sage 8.6 will also require an update of cysignals to 1.8.1.  Is that
> >>> in the works?  How would I ago about updating that package?
> >>
> >> I will take care of the packaging of cygsignals 1.8.1 the next week-end.
> >> Basically before the return of Tobias, so it should be fine.
> >
> > Thanks!
> >
> >> Note that the packaging of cygsygnals is tricky, so I would prefer to manage it.
> >
> > Out of curiosity, what's tricky about it?  I noticed that there's a
> > python-cysignals-base, and python-cysignals-pari (the latter being the
> > one required for Sage).  Does it have to do with that?  I wonder if
> > there's anything that could make it easier (it really *shouldn't* be
> > hard...)
>
> What is tricky is the integration with the Debian machinery to build Python packages
> and the fact that Cygsignals mix Python and autotools tools for setting up:
> Python and autotools set up machineries are not friendly to each other,
> and cython is not as flexible as C can be (regarding flags).

Interesting--in the past I have complained about cysignals doing
exactly this, because it is non-standard.  On the other hand, the only
alternatives I can think of would be something like SCons or Waf, and
I'm not as familiar with them, plus I don't see anything inherently
wrong with calling an autoconf script from Python, so I kind of
resigned to it.

Would it create less trouble for debhelper if the configure script for
cysignals weren't at the top-level of the source?