On Nov 1, 12:10 pm, Abdulaziz Ghuloum <[EMAIL PROTECTED]> wrote: > On Nov 1, 2008, at 3:27 AM, marcomaggi wrote: > > > When I install a .sls file and its precompiled .ikarus-fasl > > in a Slackware package, line 37 in "ikarus.load.ss": > > > [(<= (file-ctime ikfasl) (file-ctime filename)) > > > causes ikarus to refuse the fasl because the ctimes are > > equal (at the second). The Slackware package management > > does not allow to preserve the timestamps. > > That looks like a fine change to make, but I and some others > who are more knowledgeable in this area need to double-check > the implications.
Rethinking of it I am probably wrong in saying that changing <= to < would fix the problem. The seconds count can always flip between the creation of the two files during unpacking, so the change would not be a reliable solution in this case and in all the other cases I can think of. More below for packages. > Can you post a bug report about this? Yes. > > Yes, fasl files can be created at installation time > > Is compiling a bunch of libraries really that complex? After more investigation, it goes like this: the Slackware package management is supposed to avoid removal of files created by installation scripts. So if at installation time I run "ikarus --compile-dependencies" from the installation script, at package removal time the fasl files will be left behind (no UNinstallation script will be executed). I still have to test it, but copying from what is done with Emacs: it seems that the solution is to create two packages, one with the .sls and one with the fasl files. > > By the way: why ctime and not mtime? > > I was supposed to change that to mtime, thanks for the > reminder. > > > Why a is chmod allowed to reverse the "newliness"? > > I don't understand this question. Using ctime a chmod on a .sls file will change the seconds count, making it "newer" than its fasl. (It is a typo, it should have been "newlyness").
