Control: clone -1 -2 -3
Control: retitle -2 bcc: provides c-compiler while not providing cc alternative
Control: retitle -3 pcc: provides c-compiler while not providing cc alternative
Control: reassign -2 bcc 0.16.17-3.3
Control: reassign -3 pcc 1.2.0~DEVEL+20200630-2
On Thu, 27 Jan 2022 at 19:07:34 +0200, Adrian Bunk wrote:
> There is no defined semantics what "c-compiler" actually provides,
> e.g. 'cc' might or might not be provided.
If a package providing c-compiler isn't guaranteed to provide any
particular interface, then what's the point of the virtual package?
I don't think we should have virtual packages that say nothing actionable
about interfaces: that's just a trap for the unwary.
> There are mysterious ppc64el debci failures that might be
> related to bcc being installed on ppc64el while tcc gets
> installed on other architectures.
Your analysis seems correct: the gcc family, the clang family and tcc
provide the /usr/bin/cc alternative, but bcc and pcc do not. ikiwiki-hosting
calls cc, so it will be OK with tcc but will fail with bcc or pcc.
I think this is a bug in bcc and pcc: either they are sufficiently
general-purpose C compilers that they can provide the /usr/bin/cc
alternative, or they are not sufficiently general-purpose and therefore
should not provide c-compiler.
(No value-judgement intended: it's fine to have special-purpose compilers
that are useful for some purposes but not suitable for general use, as long
as we don't mislabel them as though they were more general-purpose.)
I'll change ikiwiki-hosting-web to require something like gcc | clang | tcc
as a workaround (let's keep bug number #1004436 for that), but it seems
likely that many or perhaps all of the other packages that require c-compiler
(cargo, dkms, icecc, intercal, iraf-dev, laby, libalien-wxwidgets-perl,
libdevel-checklib-perl, libinline-c-perl, libtool, urweb) would have
the same problem, so I'm cloning this to bcc and pcc.
I think a sensible place to draw the line might be that if a compiler
can compile a C program and link it to the ordinary precompiled library
stack that we ship in Debian, then it should provide both c-compiler and
the /usr/bin/cc alternative, otherwise it should provide neither of those?
I think that would mean that pcc should start providing /usr/bin/cc and
continue to provide c-compiler, while bcc should continue to not provide
/usr/bin/cc and also stop providing c-compiler (based on experimenting
with slightly modified versions of libsdl2's debian/tests/build that
use tcc, pcc and/or bcc instead of gcc/clang: the test succeeds with
pcc but fails with bcc).
smcv
