Martin Husemann <martin%duskware.de@localhost> writes: > I know the world outside there is crazy and functional+lean is no upstream > target anywhere, but I just ran into a tiny pkg that is bloated a > lot by stuff I never use (sorry, best criterium I can come up with): > > graphics/inkscape is a relatively leightweight simple vector graphics > program. > > It comes with a bunch of extensions, and some of them rely on py-numpy, > which itself comes with the whole heavy burden of fortran libs and the > required gcc-from-pkgsrc build on NetBSD. > > Splitting inkscape into "inkscape" and "inkscape-numpy-extensions" would > avoid this, but I know this is not the prefered pkgsrc way. Is this a build cost issue or an installation cost issue? One question is upstream norms. I would guess that the build with numpy is normal and without is deficient, and thus those names are backwards. I also don't follow "splitting" as without a plugin architecture this doesn't really work usually. There is a tradition of having a base package and plugins. By plugin, I mean that inkscape-foo depends on inkscape-base and numpy, and inkscape-base does not depend on numpy, and inkscape depends on all, and when you install inkscape that starting inkscape is like it is now. One could also take the view that it's a NetBSD bug not to have fortran in base. How bad is this, once there is fortan? I have inkscape built because I intend to learn how to use it someday, and it's 176 MB (netbsd-9 amd64, pkgsrc-head). It also seems like there are a lot of extensions that use of extensions is pretty important in general. Assuming plugins work, I am a bit uncomfortable about splitting solely on numpy, as that feels hacky, but I don't understand their plugin space. Have you been able to build inkscape with a few things commented out and disabled? There is also the options approach, but that doesn't work well with distributing binary packages.
Attachment:
signature.asc
Description: PGP signature