Re: [Debian-science-sagemath] name of arb library in Debian and adjustments needed

[Dima Pasechnik]

On Fri, Jul 12, 2019 at 11:58 AM Jerome BENOIT <calc...@rezozer.net> wrote:
>
>
>
> On 12/07/2019 14:39, Dima Pasechnik wrote:
> > On Fri, Jul 12, 2019 at 11:36 AM Jerome BENOIT <calc...@rezozer.net> wrote:
> >>
> >>
> >>
> >> On 12/07/2019 10:31, Dima Pasechnik wrote:
> >>> I've run into the fact that Debian ships an unusally named arb library
> >>> (libflint-arb.so rather than libarb.so)
> >>> on https://trac.sagemath.org/ticket/27270
> >>> and I wonder how to adjust the rest of Sage to use it.
> >>>
> >>> Could you point me at the corresponding patch(es)?
> >>
> >> This choice is made to avoid name collision.
> >> I am not so sure of what you want.
> >> The patches are applied as Debian patches (read debian centric patches).
> >>
> >> Ideally arb would come with a pkg-config meta data file.
> >
> > I agree - there is https://github.com/fredrik-johansson/arb/issues/272
> > to deal with this. Probably we need to ping Fredrik (in CC) on this.
>
> It must be kept in mind that arb is the end of a long chain of libraries that do not come with pc meta data files,
> the first of the chain being GMP. A more practical idea is to write a m4 file. You can write your own m4 file
> without waiting for upstream work.

A quick way would be to create src/sage/env.py.in, with a template for, say,
`aliases["ARB_LIBRARIES"]` in `cython_aliases`
filled in by a call to AC_CONFIG_FILES.

This would be setting a precedent for sagelib (there are so far no
Python files treated this way).

I wonder whether this might create extra issues for packaging.

Dima






>
> Jerome
>
> >
> > Dima
> >
> >>
> >> hth,
> >> Jerome
> >>
> >>
> >>>
> >>> Thanks,
> >>> Dima
> >>>
> >>> _______________________________________________
> >>> Debian-science-sagemath mailing list
> >>> Debian-scie...@alioth-lists.debian.net
> >>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
> >>>
> >>
> >> --
> >> Jerome BENOIT | calculus+at-rezozer^dot*net
> >> https://qa.debian.org/developer.php?login=calc...@rezozer.net
> >> AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
> >>
> >> _______________________________________________
> >> Debian-science-sagemath mailing list
> >> Debian-scie...@alioth-lists.debian.net
> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
> >
> > _______________________________________________
> > Debian-science-sagemath mailing list
> > Debian-scie...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
> >
>
> --
> Jerome BENOIT | calculus+at-rezozer^dot*net
> https://qa.debian.org/developer.php?login=calc...@rezozer.net
> AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
>
> _______________________________________________
> Debian-science-sagemath mailing list
> Debian-scie...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath

[Dima Pasechnik]

I've implemented the latter, please review
https://trac.sagemath.org/ticket/27270
Hopefully it will allow to get rid of
https://salsa.debian.org/science-team/sagemath/blob/master/debian/patches/d0-arb.patch

[Antonio Rojas]

El lunes, 15 de julio de 2019, 14:49:54 (UTC+2), Dima Pasechnik escribió:

A quick way would be  to create src/sage/env.py.in, with a template for, say,
`aliases["ARB_LIBRARIES"]` in `cython_aliases`
filled in by a call to AC_CONFIG_FILES.

This would be setting a precedent for sagelib (there are so far no
Python files treated this way).

I wonder whether this might create extra issues for packaging.

Dima

Yes, it does. This makes sagelib compilation depend on sage's own build system which is a big step back for distro packaging. In fact with this patch I can no longer build standalone sagelib, trying to run configure fails with 

aclocal: error: m4/sage_spkg_collect.m4:57: file 'm4/sage_spkg_configures.m4' does not exist

 

[François Bissey]

And here I don’t run configure at all in sage-on-gentoo. I only use python standard
tools to build the sage library itself. I could fix it but this is an annoyance I don’t need.

François

[arojas]

El martes, 16 de julio de 2019, 0:07:19 (UTC+2), François Bissey escribió:

And here I don’t run configure at all in sage-on-gentoo. I only use python standard
tools to build the sage library itself. I could fix it but this is an annoyance I don’t need.

François

Neither do I - but with this patch there is no choice 

[François Bissey]

The choice is manual. You process the `env.py.in` manually in your preparation
phase. Which is terrible of course but better than running configure.
And since I am building multiple python having to run configure is really a pain
in the ***.

François

[Dima Pasechnik]

On Mon, Jul 15, 2019 at 11:15 PM François Bissey <frp.b...@gmail.com> wrote:
>
>
>
> > On 16/07/2019, at 10:11 AM, arojas <nqn...@gmail.com> wrote:
> >
> >
> >
> > El martes, 16 de julio de 2019, 0:07:19 (UTC+2), François Bissey escribió:
> >
> > And here I don’t run configure at all in sage-on-gentoo. I only use python standard
> > tools to build the sage library itself. I could fix it but this is an annoyance I don’t need.
> >
> > François
> >
> > Neither do I - but with this patch there is no choice
>
> The choice is manual. You process the `env.py.in` manually in your preparation
> phase.

by the way, in this file there is something else that should be fixed, namely
the line

aliases["LINBOX_CFLAGS"].append("-std=gnu++11")

which hardcodes `std` value, something that can produce C++ API bugs
(it should instead be parametrised and filled in by `./configure`...)

You may of course go ahead and replace this with `.pc` config file for arb,
but don't ask me to implement this.
(this is something that should be upstream, but upstream runs its own
iffy build system,
not autotools, etc etc)

> Which is terrible of course but better than running configure.
> And since I am building multiple python having to run configure is really a pain
> in the ***.
>
> François
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2F1D4AA1-40BB-43FD-A48B-1F8C6D8FE600%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[François Bissey]

For those not reading the ticket.
Dima:
well, I don't see a point of not running ./configure. Perhaps it was fashionable in Python world 10-15 years ago :-)

My answer:
It is an interesting comment about configure. Unfortunately, as far as I know running configure
for a python project is still not a done thing. It doesn't mesh with the other elements of the
python toolchain. There is certainly room for some configurability option in sage in regards to
the optional libraries. But autotool's configure is definitely not the python way. Apart from
cypari I cannot think of another python package using configure.

Let's be honest, a small configure script for sage's optional stuff and the possibly unusual stuff
would be fine to run. The full configure script for the whole of the distribution is inappropriate.
It all goes back, once again, to "sagelib" being treated special instead of as a normal package.
So many things would have to click in place once you do that. Other superbuild systems like the one
for paraview don't treat the main target in a special way like sage's does.

—
François

[Dima Pasechnik]

One way or another, we need to move forward on
https://trac.sagemath.org/ticket/27270
--- if you have a better solution than there, implement it, if not,
accept what it already provided.

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/820236E3-2C69-460E-94F9-7140C1AFA911%40gmail.com.

[François Bissey]

I will not give it a positive review. I won’t prevent other people to do so.
But I will not put my name on this.

François

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq2fzJ2u5SLcgNTZKnuCnEtYaY%2Bb%3DYgXCWpfF%2Byb7D3F7g%40mail.gmail.com.

[François Bissey]

My contingency plan for sage-on-gentoo is
sed “s:@ARB_LIBRARY@:arb:” src/sage/env.py.in > src/sage/env.py
Replace “arb” and the paths with what is appropriate for your distribution.

[Dima Pasechnik]

On Tue, Jul 16, 2019 at 1:13 AM François Bissey <frp.b...@gmail.com> wrote:
>
> My contingency plan for sage-on-gentoo is
> sed “s:@ARB_LIBRARY@:arb:” src/sage/env.py.in > src/sage/env.py
> Replace “arb” and the paths with what is appropriate for your distribution.

alternatively I can store an environment variable in src/bin/sage-env-config
(which, as you know, is also created by ./configure :-))
and then access it from src/sage/env.py to populate ARB_LIBRARY

This would avoid creating src/sage/env.py.in

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/F3A5787A-7136-487A-A91A-6260654203AA%40gmail.com.

[François Bissey]

Well if it is an environment variable it can be set at build time I guess.
I know I am a pain to deal with but I have done away with sage-env completely
since at least sage 8.6. And anyway, I don’t think anyone of us uses it at build time.
So it is for your benefit without getting in our way.
Now you have to make a note in the doc that ARB_LIBRARY needs to be set during build
one way or another or something of that effect.

I don’t know what other people think of it.

François

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3EDqu71PLodL-4pkN-PhMnwoscCAnPfjVrGfkRJPeuOw%40mail.gmail.com.

[Michael Orlitzky]

On 7/15/19 8:12 PM, François Bissey wrote:
> It is an interesting comment about configure. Unfortunately, as far
> as I know running configure for a python project is still not a done
> thing. It doesn't mesh with the other elements of the python

> toolchain. is certainly room for some configurability option in sage

> in regards to the optional libraries. But autotool's configure is
> definitely not the python way. Apart from cypari I cannot think of
> another python package using configure.
>

> ...

>
> My contingency plan for sage-on-gentoo is> sed “s:@ARB_LIBRARY@:arb:” src/sage/env.py.in > src/sage/env.py>
Replace “arb” and the paths with what is appropriate for your distribution.

Python packages share the same problem that C/C++ packages do with
regards to system paths. If the configuration file for the foo daemon is
/etc/foo.conf on Debian and /etc/foo/foo.conf on Gentoo, what do you do?

The right answer would be to travel back in time, and just use autotools
for python packages instead of reinventing the wheel. But it's too late
to shoehorn that into the whole ecosystem now.

So, in practice, we get one of two solutions. Either the distributions
patch everything (like you're planning to do above), or every python
package has to reinvent parts of autotools, for example:

https://git.launchpad.net/dkimpy-milter/tree/setup.py

Either one is fine. Even though autotools would be "the right way" in my
opinion, I don't bother with it in my own packages -- like you said, it
doesn't work well with the existing tooling (I prefer shorter ebuilds).