Re: Multiple/Split Master Sites?

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

Jon Buller <jon%Bullers.Net@localhost> writes:

> Adam Hoka wrote:

>> You may have a look at wip/sbcl and wip/sbcl-boot in pkgsrc-wip.
>> (pkgsrc-wip.sf.net if you dont know the wip project)
>
> I really don't mean this to sound rude, but I'm unable to think
> of a more diplomatic way to put this at the moment.  Please
> forgive me, and filter that part out if you can...
>
> Have you actually read what I wrote, and looked at your
> suggestion?

Yes, I did. And I think that you're trying to solve the wrong problem.

The experience of sbcl/sbcl-boot packages shows that the problem
is not in having multiple master sites, but in the following:

1. "make update" deinstalls first, then tries building package,
which is wrong, since when package is broken, "update" not just doesn't
update, it leaves system in undesirable state.  This should be fixed
independently, without taking into consideration self-bootstrapping
packages.

2. Bulk build system prevents cyclic dependencies.

I haven't investigated this problem yet, but this is still essential
to support self-bootstrapping packages like sbcl, gforth, or any other.

> Did you notice that huge block of comments in both
> the pkgsrc and wip Makefiles that says CLisp probably won't
> work?

And if you follow SBCL development, you couldn't pass the fact,
that SBCL 1.0.15 bootstraps with CLISP.

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

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


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