#20136: Upgrade meataxe and fix some build issues
-------------------------------------+-------------------------------------
Reporter: jdemeyer | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-7.2
Component: packages: | Resolution:
optional | Merged in:
Keywords: | Reviewers: Jeroen Demeyer
Authors: Simon King | Work issues:
Report Upstream: None of the above | Commit:
- read trac for reasoning. | 96fc74f2b7d5aa908d28376673e014828375e4c7
Branch: | Stopgaps:
u/SimonKing/various_meataxe_build_issues|
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Replying to [comment:64 tscrim]:
> In order to use meataxe, you need to rebuild Sage because of the
optional extension. So I would think you would need a certain amount of
write access.
During ''installation'' of the package, of course it is granted that the
person who is installing it has write access to SAGE_LOCAL. However,
during ''usage'' of Sage, it is granted that the user has ''read'' access
to SAGE_LOCAL and ''write'' access to DOT_SAGE, but not necessarily write
access to SAGE_LOCAL.
> Although if that is an issue, I think one way we can fix it all is
during installation, there could be a flag which we set that determines
where the data files are written to and read from. Otherwise I am not sure
how to make this really usable in a multiuser environment.
Of course it is usable in a multiuser environment, because it is not a
problem if each user has her own copy of the multiplication tables.
I think I have explained above the two possible approaches that one could
take:
- Current approach I take: Patch !MeatAxe, so that it becomes possible to
set a flag at run time telling !MeatAxe to read tables from and write
tables to a specified directory. Since it is during run time, it
'''must''' be a directory where the user has write access, hence, DOT_SAGE
but not SAGE_LOCAL.
- Alternative approach: By a relatively recent upstream change, !MeatAxe
would finally read from, but still not ''write'' into, the directory
`MTX_ROOT/lib`, where `MTX_ROOT` is the directory into which !MeatAxe is
installed; if a table cannot be found there, upstream would write into the
current directory, which may be forbidden for the Sage user, resulting in
an error (or without my patches, it wouldn't give an error but just
crash). Of course we would have `MTX_ROOT=$SAGE_LOCAL`. Consequences:
1. It would become mandatory to write ''all'' multiplication tables
during installation of the package, since otherwise write permission
cannot be granted and since we don't want the current directory to be
polluted.
2. We would never be able to use the "big" !MeatAxe kernel for large
field sizes, simply since it wouldn't be feasible to compute and write ten
thousands of multiplication tables during installation. However, the big
kernel isn't officially supported by upstream nowadays.
3. As I said, upstream would use `MTX_ROOT/lib`, i.e.
`SAGE_LOCAL/lib`, for its tables --- but that's awful. To the very least,
it should use a single sub-directory such as `MTX_ROOT/lib/meataxe_tables`
for that purpose. Hence, we would need yet another patch to upstream.
- Mixed approach: Patch !MeatAxe as in the current approach, use a single
location to which all users have read but not necessarily write
permission, and create the tables during package installation.
--
Ticket URL: <http://trac.sagemath.org/ticket/20136#comment:65>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
