Since it sounds like consensus is that (1) libbitcoin-blockchain will
not be ready in time, and (2) that accepting Obelisk protocol breaking
changes will be problematic, we have a clear path.

Given that it will take some effort to get the version1 build up to the
desired reliability, and that this will likely extend the lifespan of
version1, I would like to take on a couple of work items that had
previously been avoided.

The objective would be to (1) achieve a similar level of reliability and
maintainability as version2, in build, platform support and
installation, (2) present consistent libbitcoin toolkit names and
repository locations, and (3) avoid extending maintenance for deprecated
spesmilo repos.

The changes would be:

1) Change the libbitcoin-build generation for libbitcoin-server from the
/protocol feature branch to a /version1 branch. Note that
libbitcoin-server is a fork of Obelisk, and that Obelisk does not
require sx or libwallet.

2) In libbitcoin-server/version1 rename libobelisk to libbitcoin-server
and obelisk to bitcoin-server. This is already in the roadmap but was
deferred in anticipation of the blockchain/protocol changes.

3) Add a libbitcoin-server script to register the server daemon(s). This
capability can then be generalized into libbitcoin-build so as to
incorporate it into the generated install script and executed via Travis.

4) Move libbitcoin/obelisk to spesmilo/obelisk. This is for
deprecation/archival of the old name. This would result in the first
consistent set of libbitcoin-* repositories.

Note that BX speaks the original Obelisk protocol. Building BX
side-by-side with libbitcoin-server would require a prefix build, since
it builds against libbitcoin/version2 and libbitcoin-server will
currently require libbitcoin/version1. However there are signed portable
single file binaries for BX, so there is also the option to not even
build it. Once we transition libbitcoin-server to libbitcoin/version2
this issue will go away.

WRT packaging, I would like to incorporate package generation metadata
into libbitcoin-build. Richard, if you can provide a packaging script,
or even just a rough outline for starters, I can generalize it into
libbitcoin-build.

e

On 01/02/2015 03:10 PM, caedes wrote:
> On 02/01/15 19:49, rdks wrote:
>>> The goal is to produce an easy-to-install Darkwallet server, so
>>> there's no point in packaging the version2 stuff if its server part
>>> isn't ready yet. It would make more sense to package version1 for now.
>>
>> That basically is what I would have concluded, too.
>> So I think the primary goal for Pablo and me would now be to get the
>> version1 stack packaged so that it will preferably be available along
>> with darkwallet 1.0.
>>
>
>
> Ok, we should start by having a page on the wiki for tracking this. I
> think you should have enough information to start that, or if you
> prefer, I can start it then you can maintain it.
> Once we can track versions we need then we can track packaging status.
> Some packages are really easy to make even if not ready, while others
> can be painful.
>
> I guess we can start with: https://wiki.unsystem.net/en/index.php/Packaging
>
> But should be converted to a table format, and have rows for target
> version and package status.
>
> Then we can add a little howto below or somewhere else.
>
> Cheers!
>
>
>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>