<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 6, 2018 at 4:05 AM Torvald Riegel <<a href="mailto:triegel@redhat.com" target="_blank">triegel@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 2018-09-18 at 21:48 -0500, Rene Rivera wrote:<br>
> On Mon, Sep 17, 2018 at 9:05 AM Rene Rivera <<a href="mailto:grafikrobot@gmail.com" target="_blank">grafikrobot@gmail.com</a>><br>
> wrote:<br>
> <br>
> > This is one of two papers I would like SG15 to consider for the next<br>
> > meeting.<br>
> > <br>
> > <<br>
> > <a href="https://rawgit.com/bfgroup/std_cpp/master/doc/package_ecosystem_plan_Dx" rel="noreferrer" target="_blank">https://rawgit.com/bfgroup/std_cpp/master/doc/package_ecosystem_plan_Dx</a><br>
> > xxx_R0.html<br>
> > > <br>
> <br>
> I now have a paper number for this. And I've updated the page with that.<br>
> You can read it here now:<br>
> <br>
> <<br>
> <a href="https://rawgit.com/bfgroup/std_cpp/master/doc/package_ecosystem_plan_D117" rel="noreferrer" target="_blank">https://rawgit.com/bfgroup/std_cpp/master/doc/package_ecosystem_plan_D117</a><br>
> 7R0.html<br>
> > <br>
<br>
This is a very ambitious plan, and scope.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At least judging from this paper, I have concerns that this is approaching<br>
the problem from the wrong angle. Specifically, it starts from the<br>
perspective of what tools to use. </blockquote><div><br></div><div>It starts from the perspective of what tools we are currently using, i.e. existing practice.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> That's the simpler part of a<br>
tooling/dependency/marketplace ecosystem, and it's not the part one should<br>
start with IMO.<br></blockquote><div><br></div><div>I'm confused.. is it a "very ambitious plan" or the "simpler part"? Those seems contradictory to me.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The paper didn't make it clear to me what stages of a software lifecycle<br>
you want to cover: Build only? Build with binary dependencies? Testing? <br>
Deployment? Deployment with a specific update/upgrade mechanism?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You seem to want to allow binaries in packages, so that brings in<br>
deployment problems (at least for your build system) even if you're just<br>
intending to cover the build phase.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Critical parts like the UPID are just mentioned but not covered in detail. <br>
I'm not interested in seeing any discussion of how to specify the<br>
identifier (eg, that it's a string and has components X Y Z with a<br>
particular formatting) -- but what needs to be discussed is how this is<br>
supposed to work on an abstract level: Who controls the namespace? What is<br>
actually a part of the UPID? Is it upstream source only, or is it about<br>
builds too? Can there be multiple variants/branches (eg, based on an<br>
upstream source with security-fix backports)?<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The paper also doesn't cover the industry realities and business aspects<br>
that one needs to consider when the target scope is an "ecosystem". <br>
Vendors won't stop wanting to differentiate or control markets just because<br>
we create a C++ proposal.<br>
For example, you write that it would be nice to have a single global index.<br>
I'd bet against this happening for any index of sufficiently large<br>
relevance for the industry. Controlling the major index would mean control<br>
of access to the major marketplace for C++ packages -- which is something<br>
both vendors and regulators would happily fight over. One can't go to<br>
Amazon and simply list something there under one's own terms; same at<br>
Google Playstore, and all the other "marketplaces". Another example even<br>
more similar to the package index are registries for Linux Containers:<br>
there are common interfaces for containers, but there are several<br>
registries for both business and technical reasons.</blockquote><div><br></div><div>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.</div></div><div dir="ltr" class="m_-2331063679110036517gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br></div></div></div></div></div>