feat: private slices

[lczyk]

• Have you signed the CLA?

---

following some recent good use-cases in chisel-releases (systemd, squid), i thought i'll attempt a proof-of-principle implementation of private slices in chisel. this is a major feature and i'm not taking it's implementation lightly. this PR is an opinionated attempt just to have some code to discuss / bring to light all the design decisions made.

AI DISCLOSURE: written using Claude 4.6. i then read and edited/rewrote the generated code.

with that said:

context

see, for example, this (short) discussion.

ideally we want all the slices to be functional -- if someone cuts just that slice they get something which makes certain amount of sense and it works. e.g. if the slice is a bash script, it has bash as an essential etc. sometimes though there are very big slices like systemd_stabdard where we then extracted a bunch of components into separate slices just to keep it organised. these slices should be as functional as possible, but it sometimes does not really make sense / is not possible to make them functional by themselves and we're forced to inline them. with private slices we would be able to organise layout of such big slices better. this is a feature purely for chisel-releases maintainers and contributors. it makes organisation of files in slices much more manageable.

this PR

introduce private slices -- slices which can only be used internally as essentials, but can not be cut. any slice who's name begins with _ is private. they are then referenced as e.g. mypkg__priv in essentials. this does not break any existing slices since _ was not a valid character to start the slice name with.

here are the main design decisions / considerations i've come across:

1. exactly one optional leading _. the minimum length requirement (>= 3 chars) applies after the optional _, so the shortest valid private slice name is _abc. __abc is invalid since it starts with two _'s.
2. find _foo already means "match slice name only, any package". rather than breaking that ux, private slices are never returned by find -- even when other queries would otherwise match them. i'm unsure how bad it would be to change the ux for the find command, so i've leant on the side of non-breaking changes.
3. chisel info on private slices is allowed because it didn't break anything. trivial to disallow.
4. private slices are recorded normally in manifest.wall since it's used for SBOM generation and that information is needed there.
5. cross-package references are allowed. a public slice in foo may list bar__priv as essential. this is the more permissive version of private slices. one where private slices are private to the package would also be useful. i just decided to go with this one for the sake of the initial proposal.
6. private slices are available in v3 only: _-prefixed names continue to be rejected in v1 and v2. since _-prefixed names were previously rejected by the slice-name regex in all formats, no existing release can rely on them, so gating to v3 is not a breaking change for v3 either. i can see an argument for it being a v4 thing though, although again, i don't think this would be a breaking change, so it does not, in principle, warrant a v4
7. if a release contains unreferenced private slices, it is rejected. this is an opinionated decision and i chose to be strict here.
8. cmd cut rejects private slice arguments at the CLI layer since it can detect them fast and fail fast. setup.Select also rejects private keys as a stronger guarantee.
9. forward-compatibility caveat: an older chisel binary reading a new release
   that uses private slices will fail at slice-name parsing. the failure is
   loud and immediate — not silent. this is the same risk profile as any
   additive grammar change. an alternative approach would be to e.g. add private: field to slices and not rely on _(?) lots of simmilar considerations mentioned above would still apply though.

edit:

10. it could be useful to sometimes be able to slice private slices, even if just for the sake of some skeleton tests / to copy cut the private slice into a temp rootfs and then copy some files out of it. maybe chisel cut package__private --ignore=private as an api for that ...? 🤔 for now i left that as out of scope. let's see where the discussion goes.

[upils]

@lczyk would you mind giving more details on the original need? What problem would that solve exactly? Can you point at PRs or previous discussions so I can better understand the context?

[lczyk]

@lczyk would you mind giving more details on the original need? What problem would that solve exactly? Can you point at PRs or previous discussions so I can better understand the context?

i did just kindof leave that context in my head didn't I ... 😅 i've added the context section above ( + one more thought - n10 )

[upils]

Thanks for the additional context. I have some questions:

1. IIUC this is only to split in multiple slices what is always logically a single slice, is that correct?
2. Do you already see cases where some members of a private slice group would not all be declared as essentials on a slice?
3. Why is there a need to organize these slices? Do we expect to update these slices at a different pace?
4. Do you have already other packages in mind that could really benefit from that? Maybe the pain you felt dealing with systemd is mostly an exception that would not really justify a feature.

Even though the find command now gives a bit more information with hint, I still expect users to go dig in the release to select what they want. So they will be exposed to the private slice concept and will have to understand it. We have to carefully consider the weight of this additional complexity in our decision.