tech-pkg archive


Re: Multiple/Split Master Sites?

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 like
a "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 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".


Home | Main Index | Thread Index | Old Index