Re: Multiple/Split Master Sites?

[Aleksej Saushev <asau%inbox.ru@localhost>]

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
nearest future.

>> 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.


-- 
CKOPO BECHA...
   CKOPO CE3OH...