1) slib-3.1.4 installs to /usr/lib -- former versions used /usr/share/guile/site/slib Why? Why don't you use /usr/share/slib? (Debian does it <http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=slib&version=stable&arch=all&number=all> for example.) From FHS (<http://www.pathname.com/fhs/pub/fhs-2.3.html>): "/usr/share : Architecture-independent data Purpose The /usr/share hierarchy is for all read-only architecture independent data files. This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS. Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose." 2) dev-scheme/guile was removed from RDEPEND. You must add it to RDEPEND if you use it in pkg_postinst because if you install a binpkg only RDEPENDs need to be present. 3) The ROOT=/ test was removed in pkg_postinst. Why doesn't it fail now?
(In reply to comment #0) > 1) > slib-3.1.4 installs to /usr/lib -- former versions used > /usr/share/guile/site/slib > Why? Why don't you use /usr/share/slib? I did this because scheme code is not just data, it is code too. I could be wrong in placing it there though. > 2) > dev-scheme/guile was removed from RDEPEND. > You must add it to RDEPEND if you use it in pkg_postinst because if you install a binpkg only RDEPENDs need to be present. will fix > 3) > The ROOT=/ test was removed in pkg_postinst. Why doesn't it fail now? If the test succeeds then slib won't be registered for guile and you won't be able to use slib in guile. That is failing too. I don't know what happens if ${ROOT} != '/' without the test. There was no helpful comment.
2) is fixed
(In reply to comment #1) > (In reply to comment #0) > > 1) > > slib-3.1.4 installs to /usr/lib -- former versions used > > /usr/share/guile/site/slib > > Why? Why don't you use /usr/share/slib? > > I did this because scheme code is not just data, it is code too. But it's the same code other distributions put into /usr/share? And it's just extracted from the zip file and put there? It is arch-independent? > > 3) > > The ROOT=/ test was removed in pkg_postinst. Why doesn't it fail now? > > If the test succeeds then slib won't be registered for guile and you won't be > able to use slib in guile. That is failing too. I don't know what happens if > ${ROOT} != '/' without the test. There was no helpful comment. if [[ "${ROOT}" == "/" ]] ; then ... else elog "To register slib for guile please run:" elog "# guile -c \"(use-modules (ice-9 slib)) (require 'new-catalog)\"" elog "You have to do it yourself because ROOT was set." fi ..or something like this.
(In reply to comment #3) > But it's the same code other distributions put into /usr/share? And it's just > extracted from the zip file and put there? I don't know what other distros do. Yes, it is just extracted. > It is arch-independent? If you mean to ask whether it is machine code, then the answer is no. > if [[ "${ROOT}" == "/" ]] ; then > ... [snip] > ..or something like this. If you make me understand why it cannot ever work I'll do something like this.
(In reply to comment #4) > (In reply to comment #3) > > But it's the same code other distributions put into /usr/share? And it's just > > extracted from the zip file and put there? > > I don't know what other distros do. Often they have the same problems and sometimes they also have good solutions. > > It is arch-independent? > > If you mean to ask whether it is machine code, then the answer is no. > > if [[ "${ROOT}" == "/" ]] ; then > > ... > [snip] > > ..or something like this. > > If you make me understand why it cannot ever work I'll do something like this. http://devmanual.gentoo.org/general-concepts/install-destinations/index.html
slib-3.1.4 should now install in /usr/share/slib/ I won't do anything about the ROOT issue without a report on it failing and how and why. If the user can run some command than so can the ebuild. Closing as fixed.
(In reply to comment #6) > slib-3.1.4 should now install in /usr/share/slib/ Revbump. > I won't do anything about the ROOT issue without a report on it failing and how > and why. If the user can run some command than so can the ebuild. It fails: # ROOT="/tmp/slibfails" PORTDIR_OVERLAY="" emerge slib [...] >>> /tmp/slibfails/usr/share/doc/slib-3.1.4/README.gz * Installing slib for guile... ERROR: In procedure primitive-load-path: ERROR: Unable to find file "slib/guile.init" in load path Because slib is not installed in / but in /tmp/slibfails and you want to register slib for guile in /tmp/slibfails not for the guile in /.
So this would work then: ${ROOT}/usr/bin/guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)"
(In reply to comment #8) > So this would work then: > > ${ROOT}/usr/bin/guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)" I'd doubt it. Will it find the slib files? Where will it put slibcat and will it contain the "right" entries?
Created attachment 108488 [details] slib-3.1.4-r1.ebuild What do you think of that ? It use chroot for handling ${ROOT} , and demo a basic support of a non-guile scheme. It also fix the problem of slibcat not being build for guile on my system. But i'm not sure that building slibcat during the postinst phase is the right thing, since it will remain installed after a slib removal. I see two alternatives : * making a files/paths.scm wich would overload library-path, sub-vicinity etc with correct things for inside a gentoo chroot * providing pre-built slibcat for each supported compiler (after all, they're config files)
I had a problem relating to 1) I emerged app-office/gnucash-2.0.4-r1 and slib-3.1.4-r1 by mistake, so the usr/lib versus /usr/share issue came up. I'm not complaining, the gnucash ebuild specifies slib-3.1.1* and I emerged slib-3.1.4-r1 by mistake. (using update-world script from forums) I hope this example may help with deciding 1) above. Thanks.
slib-3.1.4-r3 should have no issues
