sdh_install installs a json file into
SAGE_LOCAL/var/lib/sage/installed/
which are then used by unistallaller
e.g. "make meataxe" produces SAGE_LOCAL/var/lib/sage/installed/meataxe-1.0.p0
{
"package_name": "meataxe",
"package_version": "1.0.p0",
"install_date": "Wed Nov 6 17:24:57 GMT 2019",
"system_uname": "Linux hilbert 5.1.12-gentoo #1 SMP Fri Jun 21
19:27:38 BST 2019 x86_64 Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
GenuineIntel GNU/Linux",
"sage_version": "SageMath version 9.0.beta4, Release Date: 2019-11-02",
"test_result": "",
"files": [
"bin/cfcomp",
"bin/chop",
...
}
I guess sdh_pip_install does not do this, I don't know.
Anyhow, it would make perfect sense to split the package into two, as
you propose.
On Wed, Nov 6, 2019 at 3:55 PM Simon King <simon.k...@uni-jena.de> wrote:
>
> Hi Eric,
>
> On 2019-11-06, E. Madison Bray <erik.m.b...@gmail.com> wrote:
> >> However, I heard rumours that in order to make a Sage optional package
> >> uninstallable, one needs some new script analogous to spkg-install.
> >>
> >> Can someone give me a pointer on what should be done in that script and
> >> what tools (sdh_*) are available for it?
> >
> > That's not quite accurate. In general you do *not* need any
> > additional scripts, with some exception.
> > These packaging guidelines still need better documentation, but
> > essentially you need to make sure the package is built for what is
> > referred in GNU standards as a "DESTDIR install" [1]. This means that
> > the package is built for installation to some particular prefix (e.g.
> > `./configure --prefix=$SAGE_LOCAL` in autoconf terms), but can then be
> > *installed* with some additional path (the "DESTDIR") prepended to the
> > prefix. This is similar to providing an alternate root (e.g. prefix
> > is appended to DESTDIR instead of just "/").
>
> Then what to do with p_group_cohomology? Its spkg-install script
> installs two sub-packages. Each of them, I think, follows the above
> scheme. However, Sage has no way of knowing that uninstalling
> p_group_cohomology means uninstalling two sub-packages.
>
> Perhaps one possibility is to split the current p_group_cohomology-3.3
> into its two sub-packages, and make the first (which is autotoolized)
> a dependency for the second (which is a bunch of cython and python
> modules linked against the first sub-package.
>
> Say:
> - p_group_cohomology-3.4 shall only comprise what currently is the
> p/cython part of p_group_cohomology-3.3, and have modular_resolution
> as a dependency.
> - modular_resolution-1.0 shall only comprise what currently is the
> autotoolized c-library part of p_group_cohomology-3.3
>
> Advantage: "make p_group_cohomology" would also install the dependency,
> hence, both packages get installed. And both packages can also be
> un-installed, I suppose.
>
> Disadvantage: The only purpose of modular_resolution-1.0 would be to
> serve as a dependency, it is (to my knowledge at least) of no
> independent use.
>
> Best regards,
> Simon
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/qpuqe5%247598%241%40blaine.gmane.org.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAAWYfq22%3DK%2Bss9jhCj2L57iBOe5i9_5iUE9Kdg-ZQO_SxwM50Q%40mail.gmail.com.
