Hi all,
A while ago I synced ccache from Debian and then discovered:
(a) ccache is in main
(b) the new binary packages depend on libhiredis, which is not
This is because the new upstream version now has a redis storage backend.
It turns out that ccache has been in main essentially forever, since 2004 and there is no formal record of the motivations for including it in main. However it was and is a useful tool for developers.
There are three broad ways forward here:
(1) MIR libhiredis (it's a pretty small package that itself has no non-trivial dependencies, it doesn't actually depend on redis so that can stay in universe, but otoh it is a library that does network access in C that has had a couple of CVEs already)
(2) Build ccache without support for the redis storage backend.
(3) Drop ccache from main.
(2) would involve the least paperwork but I don't know if it's the option that best serves our users. (3) is also simple to achieve.
A while ago I synced ccache from Debian and then discovered:
(a) ccache is in main
(b) the new binary packages depend on libhiredis, which is not
This is because the new upstream version now has a redis storage backend.
It turns out that ccache has been in main essentially forever, since 2004 and there is no formal record of the motivations for including it in main. However it was and is a useful tool for developers.
There are three broad ways forward here:
(1) MIR libhiredis (it's a pretty small package that itself has no non-trivial dependencies, it doesn't actually depend on redis so that can stay in universe, but otoh it is a library that does network access in C that has had a couple of CVEs already)
(2) Build ccache without support for the redis storage backend.
(3) Drop ccache from main.
(2) would involve the least paperwork but I don't know if it's the option that best serves our users. (3) is also simple to achieve.
What do you think?
Cheers,
mwh
Cheers,
mwh
