libnss3 does not contain libsmime3.so

[tri-bao]

In file libnss3.yaml (both 22.04 and 24.04), the libs slice only take libnss3.so and libnssutil3.so. But the package libnss3 contains many other .so files https://ubuntu.pkgs.org/22.04/ubuntu-main-amd64/libnss3_3.68.2-0ubuntu1_amd64.deb.html

One of them is libsmime3.so which can only found in this package. We need it. How do you suggest to solve this case?

[rebornplusplus]

Hiya, thanks for raising the issue. Indeed, a package may not have a particular file in any of their slices due to the rationale of slicing -- get only what you need.

Ideally, you would add a new slice for the specified files or include them all in the libs slice. I have done both and raised #382 for 22.04. Feel free to raise a PR for 24.04! :)

[tri-bao]

@rebornplusplus the PR #382 has been merged. However, if I understand that slice correctly, it still doesn't not contain all the libs contains in the libnss3 package as shown in https://ubuntu.pkgs.org/22.04/ubuntu-main-amd64/libnss3_3.68.2-0ubuntu1_amd64.deb.html

The PR only adds libsmime3.so. Now if I use the libs slice, I can only have 3 .so

      /usr/lib/*-linux-*/libnss3.so:
      /usr/lib/*-linux-*/libnssutil3.so:
      /usr/lib/*-linux-*/libsmime3.so:

The following are still missing (there's libssl3.so a slice for it exists)

      /usr/lib/*-linux-*/libfreebl3.so:
      /usr/lib/*-linux-*/libfreeblpriv3.so:
      /usr/lib/*-linux-*/nss/libfreebl3.so:
      /usr/lib/*-linux-*/nss/libfreeblpriv3.so:
      /usr/lib/*-linux-*/nss/libnssckbi.so:
      /usr/lib/*-linux-*/nss/libnssdbm3.so:
      /usr/lib/*-linux-*/nss/libsoftokn3.so:

Before the PR was merged, I created a custom slice file libnss3.yaml overriding the chisel-releases' one (chisel tool does not allow different slices contain any same file). In the custom file, I add all .so to the libs slice. Now this PR is merged, which changed the ca-certificates-java_data slice. Now I got following error ca-certificates-java_data requires libnss3_nss, but slice is missing

I understand the error. Because I don't define nss slice in my file. I can add it like in your slice file. However, would you advice me the correct away to handle this situation in which the upstream official slices doesn't contain the .so we need. Is there a way we can do in our custom slice so that our build won't be broken like this case. Furthermore, one day, the upstream may create new slice for libfreebl3.so (for example), then our build will be broken again because the chisel tool doesn't allow different slice files contains the same file in section contents.

[rebornplusplus]

Ah, you wanted all the libraries! I didn't quite understand then.

Ideally, you would use slices from the upstream chisel-releases (this repo). That means, if you do need some slices (added or modified), you propose the changes, that go in and you can use that afterwards. In this case, you could raise more PRs to include all the libraries.

However, as you pointed out, you can continue to use your local slices. If you do not update the slices from the upstream chisel-releases (not recommended by the way), you should be fine because everything will work as before. (Unless, there are some changes in the packages themselves and your previous slice definitions do not address the changes.)

To merge the changes, however, you need to be more careful about grabbing all the changes from upstream. In this case, since the upstream proposed nss slice and you didn't have that, you could include that in your local slice definition.

Furthermore, one day, the upstream may create new slice for libfreebl3.so (for example), then our build will be broken again because the chisel tool doesn't allow different slice files contains the same file in section contents.

There is an important detail about conflicting files in the same package. If the paths are the same across slices in the same package, and their attributes are also the same, they do not conflict actually. So the following is fine:

package: hello
slices:
  bins:
    contents:
      /usr/bin/hello:
  all-hello-bins:
    contents:
      /usr/bin/hello*:

So, you could have multiple slices of a package declaring potentially the same file. The important bit is that, their properties should not differ. For example, the following is not okay:

package: hello
slices:
  foo:
    contents:
      /etc/hello.conf: {text: "foo"}
  bar:
    contents:
      /etc/hello.conf: {text: "bar"}

Up there, the two paths have different content. Chisel would raise an error. Had they had the same text value, it would have been fine.

However, ultimately I would encourage you to get slice definitions from the upstream and follow the earlier contribution suggestion above.