On Tue, 2018-09-18 at 21:48 -0500, Rene Rivera wrote:
> On Mon, Sep 17, 2018 at 9:05 AM Rene Rivera <grafikrobot_at_[hidden]>
> wrote:
>
> > This is one of two papers I would like SG15 to consider for the next
> > meeting.
> >
> > <
> > https://rawgit.com/bfgroup/std_cpp/master/doc/package_ecosystem_plan_Dx
> > xxx_R0.html
> > >
>
> I now have a paper number for this. And I've updated the page with that.
> You can read it here now:
>
> <
> https://rawgit.com/bfgroup/std_cpp/master/doc/package_ecosystem_plan_D117
> 7R0.html
> >

This is a very ambitious plan, and scope.

At least judging from this paper, I have concerns that this is approaching
the problem from the wrong angle. Specifically, it starts from the
perspective of what tools to use. That's the simpler part of a
tooling/dependency/marketplace ecosystem, and it's not the part one should
start with IMO.

Instead, I think this should start from the perspective of the various
different software lifecycle models that exist in practice today. Building
a small self-contained application that's unlikely to get updated is very
different from building a larger application for multiple OSes that, for
example, depends on certain libraries to be certified, has dependencies
that are maintained by another party, and does not simply use top-of-tree
as a source for updates.

The paper didn't make it clear to me what stages of a software lifecycle
you want to cover: Build only? Build with binary dependencies? Testing?
Deployment? Deployment with a specific update/upgrade mechanism?
You seem to want to allow binaries in packages, so that brings in
deployment problems (at least for your build system) even if you're just
intending to cover the build phase.

Critical parts like the UPID are just mentioned but not covered in detail.
I'm not interested in seeing any discussion of how to specify the
identifier (eg, that it's a string and has components X Y Z with a
particular formatting) -- but what needs to be discussed is how this is
supposed to work on an abstract level: Who controls the namespace? What is
actually a part of the UPID? Is it upstream source only, or is it about
builds too? Can there be multiple variants/branches (eg, based on an
upstream source with security-fix backports)?

The paper also doesn't cover the industry realities and business aspects
that one needs to consider when the target scope is an "ecosystem".
Vendors won't stop wanting to differentiate or control markets just because
we create a C++ proposal.
For example, you write that it would be nice to have a single global index.
 I'd bet against this happening for any index of sufficiently large
relevance for the industry. Controlling the major index would mean control
of access to the major marketplace for C++ packages -- which is something
both vendors and regulators would happily fight over. One can't go to
Amazon and simply list something there under one's own terms; same at
Google Playstore, and all the other "marketplaces". Another example even
more similar to the package index are registries for Linux Containers:
there are common interfaces for containers, but there are several
registries for both business and technical reasons.