mkrupcale at matthewkrupcale.com
Thu Jan 23 13:46:22 UTC 2020
On Thu, Jan 23, 2020 at 6:02 AM Boris Kolpackov <boris at codesynthesis.com> wrote:
> pkg-config is not really a package manager, it's just a way to query
> library metadata that has been built and installed in some unspecified
I didn't really mean that it's a package manager in and of itself, but
it does allow one to consume packages produced by other build systems
> What I am thinking about is the ability to specify (say, in the
> manifest) that libfoo comes from a "foreign" package manager/repository
> and have bpkg automatically call that manager to build it.
I see. To clarify, you're talking about a level above the build
system, so the foreign package manager might itself use some
alternative build system (in the case of non-binary, source packages),
right? That is, this is separate from bpkg invoking other build
> But I guess this wouldn't help distribution maintainers much since they
> replace the bpkg's functionality with the distribution's package manager.
> And that means they will have to deal with the "foreign" manager as well.
Yeah, distros will likely use the package manager / build system of
each project directly. That is unless perhaps bpkg becomes so
comprehensive/useful that they could replace all of their macros for
each system with a single set of macros for bpkg.
> Yes. One nice thing I noticed about Rust (and you can see this quite
> a bit in this thread), is that the community is not afraid to admit
> limitations or deficiencies.
Sure, acknowledging the limitations is good, but it would also be
better to address them and try to resolve them. Like I said, it was
unclear if they see this as enough of an issue to be worth resolving
since they think the parallelism can happen on the crate/package level
versus the source file level. Even then, as you said, this does not
deal with inter-crate dependencies.
More information about the users