Aleksej Saushev wrote:
And if you follow SBCL development, you couldn't pass the fact, that SBCL 1.0.15 bootstraps with CLISP.
I saw some of the activity, but never saw anything that looked likea "We'll actually make efforts to make this continue to work now." message, although I will go back and check the archives. Given how many times everyone has told me that it works, and how often it actually did, please excuse my disbelief until I see a few months of this actually being true.
I'm sorry for being rude, but you didn't reply to any my mail or PR concerning SBCL, which is why I had to start wip packages.
I don't think it was for lack of trying. I got several bounces from your ISP in what I assume was an attempt to prevent spam. I went to the web site listed in the bounce message, clicked on the right things and filled in the right forms, as near as I could tell. I then resent the message over several days, and still watched them bounce. Finally, I decided it wasn't worth the trouble.
I thought that behavior was as rude as my less than timely response, and I didn't like adding to it by spamming the list with "Please fix your SMTP server or get another ISP" messages. And to compound that problem, your first PR came in at a time when I was very busy with several other matters, so I did not get a chance to look at it for a few months. I guess I'll see if the bounces happen again, as this is going to you directly with a cc: to the list...
I would like to use a previous version of the package being built to build the next version. Something along the lines of "chroot lang/sbcl/work; pkg_add sbcl-X.X.X.tgz, although it is much more likely to just untar the package in the work directory, or maybe in work/buildtools or some such.Which is perfectly solved by "make update", if it is fixed.
I suspect the solution I made above (which was recommended by some of the pkgsrc infrastructure developers) will be considered more desirable than changing "make update" although I think I prefer that solution as well, even though it depends (a bit too much for my taste) on circularity and side effects to work.
This requires a few changes. First, a master site for the binary package that can be fetched based on OS/arch, and second the ability to fetch the source from a different master site. An alternative would be to add some bootstrap fetching, building, and updating targets to the makefile, which is sort of what wip/sbcl-boot was for. But why reinvent the wheel? Those bootstrapping tools are exactly the same as the package we are trying to build.There're not that many self-bootstrapping software around, having the special treatment in the whole framework isn't required that much.
Well, the master site is already there, it's called ftp://ftp.netbsd.org/pub/pkgsrc/packages/ along with its mirrors. And you are correct, I can only think of 2 packages off the top or my head that need this, which is why I have not made much effort at all to change any pkgsrc infrastructure to assist this. It is simply too much risk to all the other packages for not enough benefit to these two packages.
However, the reason for my message in the first place was to see if that functionality was already present and undocumented, or if someone could think of a way to work around it. The answer still appears to be "No".
Jon