<div dir="ltr">I'll let you know when/if I finish the package. :) libodb's cppget src-url property still looks the same to me from here. I imagine it's easier for now not to make separate stub bpkgs for native dependencies (I have no intention yet of maintaining them). On the topic of maintenance burden - don't forget to give cppget package maintainers the ability to transfer/share ownership. Josh</div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Nov 7, 2017 at 6:28 AM, Boris Kolpackov <<a href="mailto:boris@codesynthesis.com" target="_blank">boris@codesynthesis.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Joshua Olson <<a href="mailto:0joshua.olson1@gmail.com">0joshua.olson1@gmail.com</a>> writes: > I'm gonna see if I can make a JUCE package... Sounds good. If you would like, I can publish it on <a href="http://cppget.org" rel="noreferrer" target="_blank">cppget.org</a> (in the future there will be an automated way to do it but for now I can do it manually if you give me a git repo). > Comment: the src-url of <a href="https://cppget.org/libodb" rel="noreferrer" target="_blank">https://cppget.org/libodb</a> is broken ( > <a href="https://git.codesynthesis.com/cgit/?p=odb/libodb.git;a=tree" rel="noreferrer" target="_blank">https://git.codesynthesis.com/cgit/?p=odb/libodb.git;a=tree</a> says 'invalid > request') Fixed, thanks! > Question: if package A depends on a semi-popular package B being installed > (e.g. libcurl, webkit, gtk headers on Linux), is it ever preferable for > package B to be a bpkg too? Good question. In bpkg we have a notion of stub packages. Quoting from the bpkg manual[1]: "Version 0 (with a potential revision, for example, 0+1, 0+2) is used to signify a stub package. A stub is a package that does not contain source code and can only be "obtained" from other sources, for example, a system package manager. Note that at some point a stub may be converted into a full-fledged package at which point it will be assigned a "real" version." You can see an example of a stub here: <a href="https://git.build2.org/cgit/packaging/apr/libapr1/" rel="noreferrer" target="_blank">https://git.build2.org/cgit/packaging/apr/libapr1/</a> Currently, the only way to install a package via a stub is to tell bpkg that it is already system-installed, for example: $ bpkg build sys:libcurl libjuce In the future, however, we are thinking of having bpkg query the system package manager (e.g., apt, dnf, pkg, etc) and if the package is not installed, offering to install it. So, to put this all together, currently, if you do not want (yet) to package some dependencies but would like to list them as dependencies in the manifest, then the way to go is to create a stub. The reason you may at some point want to convert a stub to a full package is Windows: it doesn't have a system package manager (though I hear vcpkg may be becoming something like that) which makes installing dependencies painful. For example, we have started with libpq (PostgreSQL client library) as a stub but have now made it a real package which made life on Windows so much easier. [1] <a href="https://build2.org/bpkg/doc/build2-package-manager-manual.xhtml" rel="noreferrer" target="_blank">https://build2.org/bpkg/doc/build2-package-manager-manual.xhtml</a> Boris </blockquote></div> </div>