feat: custom repositories.

[oxpa]

This PR adds (rather crude) support for third party repositories.

I'm trying to build a custom image for nginx (and later - nginx-plus).
Chisel seems like a good tool for the task. But it doesn't support third party repositories.

To work around this issue I added 'url' field into chisel.yaml. This allows one to add an archive like this:

  nginx:
    priority: 20
    version: 24.04
    components: [nginx]
    suites: [noble]
    public-keys: [nginx-key]
    url: https://packages.nginx.org/nginx/mainline/ubuntu/

And then add some slices into chisel-release to install from the new repository.
I'm not sure if I have to bump any versions. I would appreciate help with this.

---

• Have you signed the CLA?

[upils]

Thanks for your contribution @oxpa.

Slices in a given release form a coupled set, ensuring no conflicts exists between any two slices. For that the release is validated by Chisel. On a regular basis the release is also validated against the actual content of packages coming from the archive. Opening this mechanism to third-party repositories would require careful consideration, regardless of the difficulty of the implementation, to ensure Chisel can still keep the strong promises it makes.

You may solve you problem by setting up an archive mirror/proxy where you would host your version of nginx. See #135 (comment) for a related discussion. Supporting mirror in a nice way is also considered for our next roadmap.

[oxpa]

I don't quite get how the "Slices in a given release form a coupled set" idea is related to what I'm trying to achieve. Nor do I understand how #135 answers my concerns.

Let's assume that I'm a software vendor and I provide a piece of software to customers. I package it into an ubuntu package and I host it in a repository. It's not an ubuntu mirror, it's a good old apt repository. And any paying customer gets access to this repository.

A customer comes to me, tells me that they are building a docker image using chisel and would like to install my piece of software into an image.

What do I tell my customer? How do they install my piece of software into a chisel "carved" ubuntu image?

In my head a reasonable approach would be: I provide them with a chisel release or a guide on how to configure chisel + a set of slices.
A customer then would then use, say, chisel release + my slices + a copy of my repository to build their docker image.

Now let's assume I have a mirror of archive.ubuntu.com. How does it help me to distribute my software?

[upils]

Thanks for clarifying your use case, @oxpa.

Now let's assume I have a mirror of archive.ubuntu.com.

Mentioning the mirror in my initial answer was slightly misleading. And given your clarification that would be infeasible.

At the end of the day, chisel-releases is a kind of distro. Chisel tries very hard to guarantee strict dependency resolution, zero file conflicts, and reproducible builds across all slices. We do this by continuously validating definitions against official Ubuntu archives. Restricting package sources to official Ubuntu archives in Chisel's code is therefore intentional: allowing arbitrary url fields inside chisel.yaml conflates static release metadata with runtime source overrides. That breaks our automated validation assumptions and opens the door to unvetted file collisions.

Distributing custom software from a private APT repository is a valid pattern, but it is conceptually closer to adding a PPA at build time rather than altering the core release specification itself.

We are open to supporting external repositories and PPAs, but it will require very careful design. For example, it would at least need to:

• Properly address how to separate what a release contains from where it is located.
• Support authentication as private vendor archives can require bearer tokens, basic auth, or custom keyrings.
• Ensure a predictable behavior when third-party packages overlap with standard Ubuntu slices.
• etc.

The list above is most probably incomplete. More research will be needed to gain a full understanding of the problem before actually looking for a solution.

Embedding repository URLs inside chisel.yaml bypasses release cohesion and intentionally hardcoded source safety checks, so we cannot accept your proposed implementation as-is. Rest assured, however, that we will consider adding this feature to our upcoming roadmap planning.

[oxpa]

@upils thank you for detailed response.
Adding this feature to a roadmap would be enough for now. I just want to make sure I won't base a solution based on a feature that will never get implemented.

As a side note, I think you are overthinking the whole chisel/chisel-release relationship. Whoever provides a release obviously responsible for it to be consistent, reproducible, tested properly, and so on. In this approach it's fine to have a patched chisel.yaml in a third party release.

But I get your point, I think. And you are absolutely correct about required features to implement it properly :) I hit at least the conflict and authentication parts.

I hope to see third party repositories implemented soon: proper support is definitely better than my "look, ma, a PPA" PR:)