Hi Leo, Leo Famulari writes: > I didn't realize / remember that Inkscape was used that deep in the > package graph. I agree, we should delay this change, at least until a > rebuild cycle. The removal of inkscape@0.92.4 should certainly be delayed, but I see no reason why we couldn't immediately, on 'master', rename the variable 'inkscape' to 'inkscape/stable', and 'inkscape-1.0' to 'inkscape', with 'inkscape-1.0' made an alias to 'inkscape', if we can agree on it. Do you see a reason to delay those changes? > I do think it's suboptimal that an end-user application like Inkscape > is depended on by so many packages... Indeed, it's not good. In fact, the question just occurred to me: "How is it that Inkscape, which clearly depends on Gtk+, can also be a dependency of Gtk+, via the path gtk+ -> at-spi2-atk -> at-spi2-core -> gtk-doc -> dblatex -> inkscape@0.92.4?" It turns out that the only reason there's no cycle here is because: (1) the older inkscape@0.92.4 uses gtk+-2 (not 3), and (2) none of the dependencies of gtk+-2 use gtk-doc. Both of these are likely suboptimal, but we will apparently be blocked from fixing these issues while Inkscape is needed to build our core graphics stack. In my opinion, the best way to fix this is to split off documentation generation for selected core libraries into separate packages. Generating documentation often requires higher-level components, and yet we should also generate documentation for our core libraries. This naturally leads to cycles unless the documentation is split off. We should use the core libraries (without docs) to build the documentation generators, and then from there build the documentation for the core libraries. What do you think? Thanks for the discussion, Mark