I won't be able to attend the Friday session, but I'd like to comment on
package management.

First of all, "package management" means lots of different things to
different people. It's a nontrivial problem in the real world. Just
look at the different approaches that exist: For example, differences in
Linux distributions (not the packaging format, but how the packaging
reflects different priorities regarding how to manage a SW lifecycle),
differences in container registries, differences in user expectactions
regarding stability vs. upgrade frequency, etc.

So, what do the proponents of standardized "package management" are
looking for in terms of functionality?

Second, why do you think "package management" is easier to solve when
focusing on just C++?
(If it's not easier than the general case, then it's unlikely that SG15
can produce something when other communities are struggling to find a
common approach.)

On Sun, 2018-03-11 at 13:35 -0400, Guy Davidson wrote:
> There are two orthogonal matters here: how to standardise the PROCESS of package management, and how to standardise the CONTENT.
>
> Does ISO C++ want to offer a source database that acts as an optional standard library extension?

What would that be, precisely? A curated registry of source code
projects? A github clone? A search engine for source code that's open
to everyone?

> I’m more interested in the second item. I think developers should be able to type at the command line something like “cpp-get std::libgraphics 1.42” and have version 1.42

What is that version actually? Is it the upstream version only without
further maintenance? Or is it with security fixes added, for example,
but also certain API/ABI stability guarantees?
Different users want different things when they say that they want a
certain version.

> of the graphics library source and all its dependencies

If you want dependencies, the version question appears again for these.
And what about dependency conflicts?

> appear in their path,

It seems you have a specific SW (lifecycle) management approach in mind.
There's more than one though.

> unencumbered by licence restrictions,

That's either a constraint on allowed licenses (which would be a highly
controversial topic) or a wish about which open source projects should
exist. I doubt this is a topic suitable for ISO standardization.

> regardless of platform, ready to build and link.

That's unrealistic, sorry. Standardization doesn't create resources and
has little control over how vendors, open-source projects etc. spend the
resources they have available.