On Tue, Nov 6, 2018 at 4:05 AM Torvald Riegel <triegel_at_[hidden]> wrote:

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

I don't think saying that we need APIs for our tools to interoperate
ambitious. Yes, a whole package ecosystem is ambitious. But that's where we
are. We need to identify not just the scope of what we need to do. But also
identify how to break it up into manageable parts.

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.


It starts from the perspective of what tools we are currently using, i.e.
existing practice.


> That's the simpler part of a
> tooling/dependency/marketplace ecosystem, and it's not the part one should
> start with IMO.
>

I'm confused.. is it a "very ambitious plan" or the "simpler part"? Those
seems contradictory to me.

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

Correct, I don't talk about any of that, intentionally. Those should be
aspects that additional papers defining the APIs and additional components
should identify.


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

I'm sorry if that personal opinion is apparent in the proposal. But, yes, I
believe that we should supports both source and binary packages. As binary
packages are a requirement for my industry.

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)?
>

Again, not including that is intentional. It should be up to some future
proposal what that UPID should be. I'm only pointing out that we need a
UPID.

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.


Indeed, I'm fairly certain this will be the hardest aspect to achieve. And
I do suspect that in the end we will end up having to deal with multiple
indices (for the simple reality that we need to supports non-public indices
at least). If we do end up with multiple we will need to define how
collisions should be handled (if at all). Yes, there are many questions to
resolve when we define how the index should operate. But we can all
hopefully agree that we need some index if we are to achieve the committee
goal of introspecting the C++ ecosystem and the user goal of accessing the
large collection of C++ libraries out there.