#16629: sage-fix-pkg-checksums munches build/pkgs/<packagename>/checksums
-------------------------------------+-------------------------------------
Reporter: charpent | Owner:
Type: defect | Status: needs_review
Priority: minor | Milestone: sage-6.3
Component: build | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/charpent/sage_fix_pkg_checksums_munches_build_pkgs__packagename__checksums|
d941afd9150164e979b7df98b2e574cdacd78053
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by charpent):
Replying to [comment:8 vbraun]:
> I've got various tarball versions of most packages. I don't want to
delete them because I might want to go back to an older ticket. Yet I get:
> {{{
> (sage-sh) vbraun@localhost:upstream$ sage-fix-pkg-checksums
> atlas-3.10.1.20140128.tar.bz2
> Version mismatch between tarball 3.10.1.20140128 and directory
build/pkgs/atlas.
> Newer version ? You must put 3.10.1.20140128.p0 in package-version.txt.
> }}}
Hmmm... Now we have a conflict on intended usage(s) (and therefore
designs) :
* The `builg/pkgs/<pkgname>/...` structure implies at most one version per
package name.
* The relevant snippet of the
[http://www.sagemath.org/doc/developer/packaging.html#checksums
Developer's guide] hints at a "batch" usage of `src/bin/sage-fix-pkg-
checksums.`
So far, that's consistent with `upstream/` as '''the''' set of active (i.
e. built by Sage's build system) Sage's external packages source tarballs.
* Your intended usage amounts to use `upstream/` as '''a''' cache of
potential external packages, the set of '''active''' Sage external
packages being determined otherwise.
a. This might be the `build/pkgs/*/package-version.txt` set, in which
case the `sage-fix-pkg-checksums` script should loop over this set and try
to find a relevant tarball. At most, it might spit a warning (or fail)
when no such tarball exists.
b. It might be an external file listing each package and the relevant
version. That makes `build/pkgs/<pkgname>/package-version.txt` redundant
(and a possible source of conflicts).
The case 1. is consistent, but needs a script like `sage-fix-one-pkg-
checksum-Volkers-style` to generate the right checksums. As said before,
the current batch-style script should loop on the `build/pkgs/...` tree.
In any case, it appears that the consistency of the proposed change (use
`upstream/` as a cache and not as a reference set) needs modifying the use
of this script (and, quite possibly, the rest of the build subsystem for
external packages). Since I do not yet know my way in this system, fixing
this is, for now, out of my reach. At a minimum, I need advice from
someone knowing what it does.
By the way, what is wrong with an external (`.gitignore`d) directory and
`mv` ing the right tarball at the right time ? An even lazier solution is,
of course, to symlink the right tarball in `upstream/`, but I doubt one
can get `git` to follow this transparently.
Since we are playing redesigning this subsystem, may I ask why we have to
have `package-version.txt` and `checksums.ini` to describe different
attribtes of the same tarball ? Why not one file ?
--
Ticket URL: <http://trac.sagemath.org/ticket/16629#comment:9>
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 http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
