feat(24.04): add bzip2 slice

[Meulengracht]

Proposed changes

Add the bzip2 package

Related issues/PRs

Forward porting

Can be proposed for 24.10 if approved

Checklist

• I have read the contributing guidelines
• I have tested my changes (see how)
• I have already submitted the CLA form

[github-actions]

Diff of dependencies:
None found.

---

[clay-lake]

Thanks this is a good package to add, although I think the bins slice needs to be split.

[clay-lake]

Some of these bins are actually scripts and probably need dash_bins and one or more base-files slices. Could we separate the executables like this xz-utils PR? https://github.com/canonical/chisel-releases/pull/338/files

/usr/bin/bzdiff:       POSIX shell script, ASCII text executable
/usr/bin/bzexe:        POSIX shell script, ASCII text executable
/usr/bin/bzgrep:       POSIX shell script, ASCII text executable
/usr/bin/bzmore:       POSIX shell script, ASCII text executable

[Meulengracht]

Why do we want to introduce dash as a dependency? What if people want to use bash?

[Meulengracht]

I asked questions in your PR so we can clarify this - I'm not sure I completely agree with this

[clay-lake]

No problem. btw that draft PR just contains some examples for another PR I was assisting, it probably wont get merged. Most of the work belongs to endersonmaia, Maybe you want to move some of the comments to -> #338

[clay-lake]

dash is the default system shell on debian based systems. It is normally linked to /bin/sh. As far as I know, users can still install and execute bash form bash_bins

Here is an example from a relatively fresh multipass instance

ubuntu@noble:~$ head -n 10 /usr/bin/bzmore
#!/bin/sh

# Bzmore wrapped for bzip2, 
# adapted from zmore by Philippe Troin <[email protected]> for Debian GNU/Linux.

PATH="/usr/bin:$PATH"; export PATH

prog=`echo $0 | sed 's|.*/||'`
case "$prog" in
	*less)	more=less	;;
ubuntu@noble:~$ ll /bin/sh
lrwxrwxrwx 1 root root 4 Mar 31 10:47 /bin/sh -> dash*

[Meulengracht]

I know it's the default shell in ubuntu, but I question whether or not it should be a forced dependency when alternatives exist and it's not a dependency for the official package. Some dependencies make sense to introduce as they are actually required to run and it's pretty binary (i.e coreutils vs not coreutils), but the choice of shell interpreter, dash is not actually a required choice.

I'm not saying I'm right here, but I just want to explain my opinion about why I think it's shouldn't be, if you and your team feel strongly otherwise I'll let it be

[clay-lake]

I question whether or not it should be a forced dependency when alternatives exist

I agree, and that is a good point. Our team had a short discussion about this recently. What if someone wanted a busybox based image? I think we need a larger discussion on this, but its probably outside the scope of this PR. Especially since some other slices use dash for the same reason.

Not to argue against my first point, but for the time being I think we should be consistent with expectations of a Ubuntu 24.04 distribution. This more reliable since it is widely used as a default shell, and it is what an end user probably expects to be there.

I'd like to hear more voices on this, I've only been on the project for a few months. :)

[Meulengracht]

@rebornplusplus @cjdcordeiro I belive we need some more input here

[clay-lake]

I had a discussion with @cjdcordeiro yesterday on this. We'll get the user to link in the shell after chiseling. The current PR should be fine then. Apologies for the confusion.

[cjdcordeiro]

Y I think this is something that may get some peace of mind once we can also handle conflicts. But for now, I can actually suggest one thing, if needed (I won't stop the PR because of this): you can create shell-specific slices. If really needed, one can have bins-dash, etc. to create options.

I'm not sure this is the ideal UX, but it surely is possible and avoids any post-inst hooks.

[clay-lake]

I had a discussion with @cjdcordeiro yesterday on this. We'll get the user to link in the shell after chiseling. The current PR should be fine then. Apologies for the confusion.

[cjdcordeiro]

lgtm but we need to test all binaries and scripts, just to make sure they're properly loaded.

And as alluded by the above discussion, if there are scripts that assume a post-inst operation, then at least leave a comment in the YAML

[linostar]

Hey @Meulengracht
Can you add simple tests for the rest of the bzip binaries/shell scripts, in addition to the comment regarding manuallylinking to /bin/sh?