# Copyright 1999-2003 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header: $ # Local variables VER="252" URLPATH="http://www.ibiblio.org/pub/Linux/apps/math/MuPAD/distrib/unix" INSTDIR="/usr/lib/mupad" INSTBINDIR="${INSTDIR}/share/bin" BINDIR="/usr/bin" RESTRICT="nostrip" DESCRIPTION="MuPAD is an open computer algebra system" HOMEPAGE="http://www.mupad.de/index_uni.shtml" SRC_URI="${URLPATH}/bin_linux_scilab_${VER}.tgz ${URLPATH}/linux_libs.tgz ${URLPATH}/share_${VER}.tgz" # If version is 2.5.2, download documentation patch if [ "${VER}" = "252" ] ; then SRC_URI="${SRC_URI} ${URLPATH}/docpatch25x.tgz" fi # License is specific to MuPad, so leave blank for now LICENSE="" SLOT="0" KEYWORDS="x86" USE="" DEPEND="" RDEPEND="virtual/glibc \ =dev-lang/tk-8.3*" S=${WORKDIR}/${P} src_unpack() { echo -n "" } src_compile() { echo -n "" } src_install() { einfo "Unpacking binary distribution ..." einfo " - Creating container directory ..." dodir ${INSTDIR} einfo " - Unpacking common files ..." tar -C ${D}${INSTDIR} -xzf ${DISTDIR}/share_${VER}.tgz \ > /dev/null 2>&1 || die einfo " - Unpacking Linux binaries for MuPAD and Scilab ..." tar -C ${D}${INSTDIR} -xzf ${DISTDIR}/bin_linux_scilab_${VER}.tgz \ > /dev/null 2>&1 || die einfo " - Unpacking support libs for Linux binaries ..." tar -C ${D}${INSTDIR} -xzf ${DISTDIR}/linux_libs.tgz \ > /dev/null 2>&1 || die # This (conditional) patch has to be last, obviously if [ "${VER}" = "252" ] ; then einfo "Unpacking documentation patch for version 2.5.2 ..." tar -C ${D}${INSTDIR} -xzvf ${DISTDIR}/docpatch25x.tgz \ > /dev/null 2>&1 || die fi einfo "Making wrapper scripts for executables ..." dodir ${BINDIR} FILES="mupad xmupad" for FILE in $FILES; do einfo " - ${FILE}" # How do I get this do "die" if it fails? cat > ${D}${BINDIR}/${FILE} <<-ENDOFSCRIPT #!/bin/sh exec ${INSTBINDIR}/${FILE} ENDOFSCRIPT fperms 0755 ${BINDIR}/${FILE} || die done } pkg_postinst() { echo "" einfo "SOME IMPORTANT NOTES:" einfo "" einfo " - This version of MuPAD has Scilab functionality" einfo " integrated, so if you have Scilab installed already, " einfo " you might find it to be redundant." einfo "" einfo " - MuPAD is only free for non-commercial use. Visit" einfo " http://www.mupad.com/ for commercial downloads." einfo "" einfo " - In this non-commercial version, you must register to" einfo " obtain a license key in order to deactivate the memory" einfo " limit. The memory limit prevents large calculations." einfo " Read the documentation or visit" einfo "" einfo " ${HOMEPAGE}" einfo "" einfo " for more info." echo "" }
To whomever is handling this submission: Some caveats about this package -- * The license for MuPAD is unique. The license file is "/usr/lib/mupad/LICENSE". I have left the "LICENSE" variable blank because this file needs to be copied to "/usr/portage/licenses" first, I guess. * The version of MuPAD that this ebuild installs has Scilab functionality built in, which might obviate (but not conflict with) a pre-existing stand-alone Scilab installation. * This edition of MuPAD is free only for non-commercial use. * The user must register and get a license key in order to disable the kernel memory limit. Best, Sourav
Hi Sourav. Thank you for the submission! However could you please repost it as attachment? This ebuild is soemwhat large and I would rather not rist copy&pasting it... George
Created attachment 9373 [details] Mupad ebuild as an attachment And here it is ... :-D
Hi Sourav. Got to this one eventually :). I tested it, looks nice. I changes the VER line to do version autodetection, also I moved docs and licens to the proper place. Then there is an issue of a license. Since the package is at least partially commercial, it is out policy to first contact package providers and ask their permission and what distribution option they prefer, if there is choice. Like in this case, package may have an (in this case optional) etch restriction imposed. I have contacted tham, will have to wait fr a reply. I'll attach the modified version to the bug meanwhile. George
Created attachment 10926 [details] modified mupad ebuild
Sounds good. In the meantime, I might try to get a gTybalt ebuild going. If you aren't familiar, gTybalt seems like the acme of all Free math packages: http://www.fis.unipr.it/~stefanw/gtybalt.html Unfortunately, the author hasn't gotten back to me.
Created attachment 11649 [details] responce from Jürgen Billing
Created attachment 11649 [details] responce from Jürgen Billing Hi Sourav. Ok, finally I got a reply from mupad.de :). Please see attached. Now I can go about adding the ebuild. George
Hi Sourav. I checked the ebuild again and committed it. Please test. BTW, I noticed, that JЭrgen Billing lists bin_linux_252.tgz in the list of files belonging to the package, but I do not see it installed by ebuild. Could you please clarify? George
"bin_linux_252.tgz" are the binaries _without_ the SciLab functionality built in. This INSTALL doc covers the installation issues: ftp://ftp.uni-paderborn.de/pub/MuPAD/distrib/unix/INSTALL
Hi Sourav. Thanks for clarification! Now that raises the following: is there any difference between the scilab that comes with mupad and the one that gets installed through portage? Or are there any interoperability issues? If now, I think we can just strip it out by using the bin_arch version of tgz. If yes, we still can make that optional. There are three ways to go about this: 1. Autodetection by testing in ebuild. The least intrusive way but does not give as much control as the other two. 2. local USE flag 3. checking some var, as is done in alsa-driver for example... Of these, 2 is probably the most "compliant" :), but as I said above - if separate scilab provided by portage may be used just as easily, we should probably just strip scilab from this one.. George
The following document describes how MuPAD interfaces with Scilab: http://www.mupad.de/BIB/MATHPADS/vol11_1toc/numerics.pdf As you can see, interfacing between the two packages is non-trivial; MuPAD comes with a version of Scilab in /usr/lib/mupad/packages/scilab/ which is not usable by itself -- it's the preinstallation sources. This source exists only to provide a back-end to MuPAD's Scilab-driven functionality. For a usable stand-alone installation of Scilab, it must be installed seperately, either from this source or Portage. I think a local USE flag is a decent idea.
* The ibiblio mirror seems to be dead, so I had to switch "URLPATH" to the official mirror: ftp://ftp.mupad.de/MuPAD/distrib/unix * You can't move the docs -- MuPAD's online help uses them, and so must stay put. The installation seems to work otherwise ...
Hi Sourav. Thanks for testing! * The ibiblio mirror seems to be dead, Made that correction to "URLPATH". We have permission to mirror the package, so it will get to ibiblio anyway :). * You can't move the docs Ok, undid this, instead I symlinked three dirs, contents of which was moved previously, into usual docs location.. LICENSE and INSTALL are still just moved (I don't suppose MuPAD's online help refers to them, or does it?). Also I incorporated mupad-noscilab useflag. If it is set, ebuild deletes /usr/lib/mupad/packages/scilab/ directory (which removes something like 50MB, so somebody might want to do this, though I am not sure how often). Unfortunately I could not find a way to make portage fetch appropriate binary based on the presense of use flag. Portage does not recognize conditionals in SRC_URI like it does in DEPEND. So the easiest way out seems to be to fetch bin_linux_scilab and just delete scilab dir if asked. Also, this is a binary package, so it should be installed under /opt (otherwise prelink may get screwed during updates. Thats in addition to FHS compliance requirement). I'll try to get around changing the ebuild correspondingly. Meanwhile I am attaching the -r1 version below. Could you please test? I am not totally sure I did it all correctly wrt scilab removal. George
Created attachment 11954 [details] modified as described above ebuild, -r1 revision
* Moving LICENSE and INSTALL should not be problematic * Handling Scilab: I find it odd that you can't use a construction like: if use 'mupad-noscilab'; then SRC_URI="$SRC_URI $URLPATH/bin_linux.tgz" else SRC_URI="$SRC_URI $URLPATH/bin_linux_scilab.tgz" fi Also, one can re-implement the function that actually fetches the source ("src_fetch"?). Another option is to just download both sources. :-) * I don't know if MuPAD can handle getting moved out of /usr ... I wounder if it expects certain things to be in certain places, like the scilab routines and docs. Maybe one can make a softlink from /usr to /opt and not have it crap out. * I don't know when I'll get to testing it ... finals are coming up next week.
Hi Sourav. >I find it odd that you can't use a construction like: >if use 'mupad-noscilab'; then > SRC_URI="$SRC_URI $URLPATH/bin_linux.tgz" >else > SRC_URI="$SRC_URI $URLPATH/bin_linux_scilab.tgz" >fi This does not work either and is prohibited. This has to deal with chaching issues - both local and server-side (this is even more in line with getting proper sources to the distfiles mirrors). The requirement is that SRC_URI does not change during ebuild "life". Thus conditional addons checking ebuild version like you did in the ebuild are fine, but conditionals on use flags are not :(. >Also, one can re-implement the function that actually fetches the source >("src_fetch"?). Yes this may be possible (like checking flag and running wget explicitly), but this also screws moirroring :). > Another option is to just download both sources. :-) This is exactly what I was trying to prevent :). Although not very large but thi is still an addition in the renage of few MB, and not all users sit on wide pipes. If possible it would be nice to care about them :). >* I don't know if MuPAD can handle getting moved out of /usr ... I wounder if >it expects certain things to be in certain places, like the scilab routines and >docs. Maybe one can make a softlink from /usr to /opt and not have it crap out. We'll find out about this shortly I guess :). >* I don't know when I'll get to testing it ... finals are coming up next week. Don't worry much about this, - the ebuild works in present form, so nothing urgent.. George
*Phew* -- finals are over. The the -r1 revision looks good! Pruning away Scilab using that USE variable doesn't seem to do anything catastrophic -- there's just an error message, and the frontend reverts to the normal backend. Cheers, Sourav
Hi Sourav. Thanks for testing! I committed the -r1 ebuild. BTW, somehow RDEPEND containing tk got commented out, however I cannot find any mention of this change in this bug. Do you have any recollection of this or any comment? (I uncommented RDEPEND for time being). Will try to look into moving the package under /opt soon.. George
> BTW, somehow RDEPEND containing tk got commented out, however I cannot find any mention of this change in this bug. Do you have any recollection of this or any comment? No. ??? That's weird.
reclosing the bug
Created attachment 31977 [details] mupad-2.5.3.ebuild drumroll...tada! Want to see if the vcam suck as much as in 2.5.2. Modifications to the ebuild: - Changed name of tbz downloaded; - Commented the superfluous stuff; - Modified version checking for -ge instead of just equalizing for docpatch
