#1141999 ITP: yojimbo -- client/server network library for multiplayer games

#1141999#5
Date:
2026-07-13 14:40:36 UTC
From:
To:
* Package name    : yojimbo
  Version         : 1.6.3
  Upstream Author : Más Bandwidth LLC
* URL             : https://github.com/mas-bandwidth/yojimbo
* License         : BSD-3-Clause
  Programming Lang: C++
  Description     : client/server network library for multiplayer games

yojimbo is a network library for client/server games with dedicated
servers: encrypted and authenticated UDP connections (via netcode),
acks and packet fragmentation (via reliable), reliable-ordered and
unreliable-unordered message channels over a bitpacked serializer (via
serialize), and per-client memory silos so one client cannot starve
another. Encryption and authentication are on by default. Stable and
production ready, in use by shipped games for ten years.

Build-depends on libserialize-dev, libreliable-dev and libnetcode-dev
(ITPs filed separately); this upload follows their acceptance. The
vendored copies of those libraries and of libsodium are stripped from
the source tarball. I am the upstream author, will maintain the
package, and am looking for a sponsor.

#1141999#10
Date:
2026-07-18 14:59:31 UTC
From:
To:
Hi Glenn,

I believe "netcode", "reliable" and "serialize" are a bit too generic as
package names. Maybe you could namespace them somehow?

Bye!

#1141999#15
Date:
2026-07-26 21:52:53 UTC
From:
To:
Hi Andrea,

Apologies for the slow reply, and thank you for raising this — you are right
that the source names are generic, and it deserved an answer sooner.

Some facts first, in case they are useful to anyone reading later:

  * There are no collisions in the archive today. None of "netcode",
    "reliable" or "serialize" exists as a source or binary package in
    Debian, and I checked before filing.

  * The binary packages are already namespaced in the conventional way:
    libnetcode-dev, libreliable-dev, libserialize-dev, libyojimbo-dev,
    plus the corresponding runtime packages. So the names a user actually
    installs and links against are not bare.

  * It is only the *source* package names that are bare.

So this is archive hygiene rather than a correctness problem, and I want to be
guided by what Debian prefers rather than defend the current choice.

I am happy to rename the source packages if you think that is the right call.
The upstream project names are genuinely "netcode", "reliable" and "serialize"
— they are a family of related networking libraries — so my instinct was to
keep source and upstream aligned. But "generic enough to be confusing in a
shared archive" is a real cost that upstream naming does not pay and Debian
does.

If a rename is wanted, my preference would be a consistent prefix across the
family rather than ad-hoc renaming, something like:

  netcode   -> libnetcode
  reliable  -> libreliable
  serialize -> libserialize
  yojimbo   -> libyojimbo   (already unambiguous, but consistency is worth
                             more than saving one rename)

That matches the existing binary names, keeps the family visibly a family, and
follows the usual convention for a source package that ships only libraries.
I am equally happy with a different scheme if you would rather — you know the
archive far better than I do.

One thing I want to state plainly: no library interface changes as a result of
this. The installed headers, the shared object names and the pkg-config names
stay exactly as they are. This is Debian source-package naming only, so nothing
downstream of the packaging is affected either way.

Just say which you prefer and I will make the change and update the other three
ITPs to match.

Thanks again for taking the time to look at these.

Best,
Rowan
(packaging these on behalf of Más Bandwidth LLC / Glenn Fiedler)