[Debichem-devel] Bug#889906: xcrysden FTBFS with libtogl-dev 2.0-1

[Daniel Leidert]

Hi,

you wrote:
> On Thu, 2018-02-08 at 18:12 +0200, Adrian Bunk wrote:
[..]
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xc
>> rysden.html
>>
>> ...
>> xcAppInit.c: In function 'Xcrys_Init':
>> xcAppInit.c:511:5: error: unknown type name 'Togl_CmdProc'
>>      Togl_CmdProc *proc;
>>      ^~~~~~~~~~~~
>
> I suspect the problem may be this: xcrysden should not use the libtogl-
> dev, because it uses modified togl sources that are included within its
> sources. It should be compiled with that modified togl files instead.

Please read this short policy section about convenience copies:
https://www.debian.org/doc/debian-policy/#convenience-copies-of-code

I wasn't aware, that you modified the shipped sources. Did you modify
other libary sources as well?

BTW: The mess has been caused by the uncoordinated upload of togl 2.0,
which uses a different API then togl version 1.7. Because of this upload,
libtogl1 will also disappear soon, making xcrysden not just unbuildable
but uninstallable too. There doesn't seem to be any effort by the person(s)
responsible for this issue to fix it, which IMO only leaves these choices:

1) Turn to the Debian release managers and/or the TC to restore togl 1.7.
There are pros and cons here and I'm not sure, this works.

2) Make an exception for xcrysden and build it against the internal copy of
togl 1.7. However, in this case it becomes mandatory that you as the
upstream author of xcrysden take over complete reponsibility for the copy of
togl you ship, including bug fixing. The first step towards this is to apply
all bug-fixes included in the last togl 1.7 Debian package into your
internal copy and make a new release of xcrysden.

3) Alternatively you could port xcrysden to togl 2.0 (seems this release is
also pretty old, so every modern system could have it). I'd suggest to not
modify the togl sources but build custom functions on top of it, if you need
modifications or new functionality. If you encounter bugs, pleaes tell us,
so this can be fixed in the library package.

3.1) There is maybe an actively maintained development version 2.1 of togl
in the netgen sources. It might work to package this netgen version and
create the togl header and library package from this copy and build xcrysden
against it. It would require that you choose to use this togl copy.

4) Last possibility is to remove xcrysden from Debian.

I'd prefer possibility 2) or 3) or 3.1) over 1) or 4).

HTH and regards, Daniel