[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Multiple/Split Master Sites?
Jon Buller <jon%Bullers.Net@localhost> writes:
> 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.
That doesn't last for long time, since SBCL is released monthly,
though I don't think the situation will change radically in
>> 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...
Well, I did have problems with my mail in past, I hope it is fixed.
Just for a note, a simple "I'm too busy to deal with it" message
is enough, we're all under heavy load from time to time.
>>> 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.
I have heard more realistic proposal of creating non-conflicting package,
which I was working on till the bootstrap problem vanished again.
I still think, that "make update" should be fixed, and I'll try
to do it myself, if noone else cares. I'll benefit from that, even
if I'm alone.
>>> 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".
Since I have some space for experiments in pkgsrc-wip, I will continue
to work on SBCL, they're going to release 1.1 next month or so,
I'd like to fix file names, which depend on working directory,
and simplify Makefile.
Main Index |
Thread Index |