Ravenports: How to Get Started?

[Carsten Mattner]

First, I'm happy it was considered but sad to hear it didn't seem
viable. More comments inline below.

On Sun, May 28, 2017 at 3:36 PM, John Marino <dragonflybsd at marino.st> wrote:

> Well, the problem with musl is that now all glibc-based libraries
> (libc, libm, pthread, etc) have to become a BUILDRUN-DEPENDS for
> most ports. Right now ravenports provides everything except libc,
> libm, libpthread, libutil, and a couple of others. If I went the
> musl route, these would both have to be provided and conditionally
> added as deps for linux.

Seems you've considered and vetted musl already, but I must admit
I don't know what would depend on libm etc. if musl is the libc.
Did I read this incorrectly?

> pros: even more compatible across linux systems, dropping even glibc ABI
> requirement

And opening the door to many users who just want to build static
binaries to their customers, which goes way beyond distro packagers
and would make the life of commercial software vendors easier. But my
use case would be purely as a private ports tree that allows me to
skip rebuilding when I want to run on musl and glibc hosts.

> cons: a lot of extra work, might need extra patches for pkg(8)
>
> so using glibc covers many/most major systems. supporting musl-based
> systems might be contract work, or at least something maybe somebody
> else would have to champion, at least for now.
>
> for example, I'd rather spend the time bootstrapping solaris. I'd
> get more bang for the effort IMO.

Which Solaris?

Are you aiming for a pkgsrc alternative?

Last question: will it stay a pure Makefile system or eventually
involve one or more of your Ada based tooling? I'm glad someone wrote
open source in Ada for a non-niche task, so I can't hide my excitement
when I imagine you might cause more adoption of Ada instead of more C
in Linux and Unix distros.

> Anyway, ftigeot gave me the idea about musl and I looked into it,
> but with the extra cost and the fact some ports aren't buildable yet
> with musl and that glibc is already pretty compatible with systems,
> I didn't look into it further.

Hmm, this is unexpected since one would expect that the ports tree has
the BSD libc patches in place and so is unlikely to require musl
fixes. But it's possible of course.