Question: is it intended to be a standalone library, or is it part of Docker?

[elboulangero]

Hi,

while attempting to package Docker for Debian, I came across this library. I first tried to package it as a standalone library, the way it's usually done in Debian, and bump into two problems, mainly:

• the library has no release yet, so I can only package a random snapshot. Not a blocker, but of course a library is better packaged when it has releases.
• the library depends on Docker, so that makes for a circular dependency with Docker (or Moby if you prefer).

So I'm just wondering what's the intent here. Does this library aims to become standalone, or is it just a part of Docker codebase that lives somewhere else for some reasons?

EDIT: I've seen that this library is also used in moby/buildkit, which is also difficult to package for the same reasons.

Thanks!

[onlyjob]

I'm curious about the same questions...

Perhaps it would make sense to start tagging semantic releases.
Tags/releases are useful to downstream package maintainers (in Debian and other distributions) to export source tarballs, automatically track new releases and to declare dependencies between packages. Read more in the Debian Upstream Guide.

Thank you.

See also

• http://semver.org/
• https://en.wikipedia.org/wiki/Software_versioning

[tonistiigi]

There is currently no intention of making release versions of this package. Every project using these helper functions needs to vendor it to their codebase, at what point they become part of these projects source. Release versions of Docker/BuildKit/img use a specific commit defined in their source when they are built.

[elboulangero]

Alright thanks for clarification!

[onlyjob]

I'm not satisfied with this explanation. If this code is meant to be re-usable, then proper versioning could be useful.

Common Golang vendoring practice is flawed. Incorporating re-usable code into larger code base makes it difficult to maintain that code, track updates, (let alone to provide incentive to do so). It is prohibitively difficult to provide meaningful security support.

@tonistiigi, if main point of your code is to "become part of these projects source" then either your code should not occupy it own name space or it should be a proper reusable library. The latter is probably true if your code is not deprecated and intended to be practically used.