/etc/ssl/certs/ca-certificates.crt is a generated file and update-ca-certificates updates this file. This causes a conflicts when updating ca-certificates. It would be better if ca-certificates excluded ca-certificates.crt and ran update-ca-certificates from post_install instead.
What sort of conflict occurs?
We have our own certs in /usr/local/share/ca-certificates which update-ca-certificates adds to ca-certificates.crt
i don't see a problem here. the ebuild already explicitly handles your case and keeps the file up to date when you emerge. the most common case is that no one customizes. that means we generate the bundle once in the src_* funcs and then deliver it in binpkgs w/no extra work. for the uncommon case where someone has /usr/local/share/ca-certificates, the ebuild runs `update-ca-certificates` in pkg_postinst. which transparently updates the /etc/ssl/certs/ bundle. you haven't described what you mean by "conflict". running emerge doesn't throw errors if files in /etc/ are customized.
I know I have seen dispatch-conf complaining earlier but now when I retest there is no conflict. Maybe this this is a relative new feature of ca-certificates? Not sure how this works as /etc/ssl/certs/ca-certificates.crt is part of the package so any change in this file should be detected by emerge.
(In reply to Joakim Tjernlund from comment #4) depends on your scale of "new" ... we've been doing this for over 5 years now. https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/?id=c4c320f01d4e0a0d8f94bdb7cc5d3dfd0c802151 i don't know what you mean by "detected by emerge". emerge is just a tool to build/install packages. it doesn't "detect" changes in installed files. if you look at the registered CONTENTS database for a package (e.g. using a tool like `qcheck`), then it would show this file as having a checksum mismatch. but that's the behavior you see for all modified config files in /etc, so i don't think this is a problem. if you have a scenario that is problematic, please describe it in detail.
