Package: ruby Version: 1:2.7+2 User: debian-cr...@lists.debian.org Usertags: ftcbfs Control: affects -1 + src:ruby-tiago
This is a difficult one, please sit down and take a cup of coffe or equivalent. I've attempted cross building ruby-tiago and it failed installing Build-Depends in mysterious ways. dpkg would print introduce an error message, but then the actual error message would go missing. Jessica Clarke quickly identified the cause and Guillem Jover quickly fixed it. Now dpkg says that the dependency on rdoc cannot be satisfied. The next bug happens to be in apt. apt and dpkg disagree on dependency resolution. When an M-A:allowed package (such as ruby) provides a package (such as rdoc), apt wrongly treats the provided package as if it were M-A:foreign. As such, apt thinks that a host architecture dependency on rdoc can be satisfied with a build architecture ruby, but dpkg disagrees. The dpkg interpretation looks more reasonable to me. Let's pretend the apt bug was fixed. Now satisying a host architecture rdoc needs a host architecture ruby. Of course such a ruby cannot be run. That's not what we want here. So we actually want a build architecture ruby. I've asked around how rdoc works and it seems like it parses Ruby and C sources rather than executing and introspecting them (like e.g. Python does). As such rdoc would be a prime candidate for being marked M-A:foregn - if it was a real package. And there we are. Providing virtual packages from a M-A:allowed package is practically broken and we'd like ruby to remain M-A:allowed while marking rdoc M-A:foreign. That's not gonna work without adding more binary packages. So I propose a number of ways foward. The obvious approach is to introduce a real M-A:foreign rdoc package. It would depend on ruby:any. It would seem kinda obvious to actually ship the rdoc binary in rdoc, but that'd result in ruby having to depend on rdoc. That'd result in a circular dependency. So maybe just leave rdoc as an empty meta package instead. The other way round would be saying that /usr/bin/rdoc belongs to the interface of ruby:any. When you want to use rdoc, you depend on ruby:any (not rdoc). That'd imply dropping the provides. No binary package depends on rdoc. Three source packages Build-Depend on rdoc. So while this seems like a regression initially, it actually solves the issue with changing just four source packages. How should we move forward? Helmut