What language flavor do you want librsvg on? I'm guessing PHP?

root@2a3ac38373b3:/# dpkg -l | grep librsvg
ii  librsvg2-2:amd64              2.40.18-1~wmf1                   amd64        SAX-based renderer library for SVG files (runtime)
ii  librsvg2-common:amd64         2.40.18-1~wmf1                   amd64        SAX-based renderer library for SVG files (extra runtime)

So librsvg is already installed, though I'm again assuming what you really want is the rsvg-* commands.

Yes, as you say it's the rsvg-* that are of interest to me. This is what I do (very happily) not on k8s (with both paths sanitised, naturally):

exec( "/usr/bin/rsvg-convert '" . $svgPath . "' -o '" . $pngPath . "'" );

exec( '/usr/bin/rsvg-convert -v' )

Neither works so I assume they either don't exist or are not available on those paths. I thought they always came packaged with librsvg but evidently not...

rsvg-convert is also a requirement for T211637: Render image previews via RSVG.

Does this ticket also involve installing rsvg for the php7.2 container?

Change 480159 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[operations/docker-images/toollabs-images@master] php72: add RSVG

https://gerrit.wikimedia.org/r/480159

From Gerrit: We need a better strategy for custom container images. We can't fall into the same hole we did with Grid Engine hosts where we just install everything people may ever need. This is not going to work with containers. @MaxSem I'm afraid we're not there yet and I'd like to push hard against even starting to pile up packages inside container images. I'm afraid there is no quick solution here.

@MaxSem May I suggest doing the compilation of RSVG locally in the tool?

In T151656#4835374, @zhuyifei1999 wrote:

@MaxSem May I suggest doing the compilation of RSVG locally in the tool?

We've had a cursory attempt at that, and got the following error on ./configure:

configure: error: cargo is required. Please install the Rust toolchain from https://www.rust-lang.org/

I'm not sure if cargo can be installed locally.

You're trying the latest RSVG which is not what WMF is running and not what is being requested here. The requested version is in C, and requires you compile GTK first, among other things.

Oh great. Dependency fun.... (Looking at the dependency for compilation in Gentoo)

 * dependency graph for gnome-base/librsvg-2.40.20
 `--  gnome-base/librsvg-2.40.20  ~amd64 
   `--  dev-libs/glib-2.58.2  (>=dev-libs/glib-2.34.3) ~amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  x11-libs/cairo-1.16.0-r2  (>=x11-libs/cairo-1.12.14-r4) ~amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  x11-libs/pango-1.42.4  (>=x11-libs/pango-1.38.0) amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  dev-libs/libxml2-2.9.8  (>=dev-libs/libxml2-2.9.1-r4) amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  dev-libs/libcroco-0.6.12-r1  (>=dev-libs/libcroco-0.6.8-r1) amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  x11-libs/gdk-pixbuf-2.36.12  (>=x11-libs/gdk-pixbuf-2.30.7) amd64  [introspection? abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  dev-libs/gobject-introspection-1.56.1  (>=dev-libs/gobject-introspection-0.10.8) ~amd64 
   `--  x11-libs/gtk+-3.24.1  (>=x11-libs/gtk+-3.10.0) ~amd64 
   `--  dev-libs/gobject-introspection-common-1.56.1  (dev-libs/gobject-introspection-common) ~amd64 
   `--  dev-libs/vala-common-0.36.15  (dev-libs/vala-common) ~amd64 
   `--  dev-util/glib-utils-2.58.2  (dev-util/glib-utils) ~amd64 
   `--  dev-util/gtk-doc-am-1.25-r1  (>=dev-util/gtk-doc-am-1.13) amd64 
   `--  virtual/pkgconfig-0-r1  (>=virtual/pkgconfig-0-r1) amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  dev-lang/vala-0.36.15  (dev-lang/vala) ~amd64  [vapigen(+)]
   `--  dev-lang/vala-0.34.16  (dev-lang/vala) amd64  [vapigen(+)]
   `--  dev-lang/vala-0.32.1  (dev-lang/vala) amd64  [vapigen(+)]
   `--  app-portage/elt-patches-20170826.1  (>=app-portage/elt-patches-20170815) ~amd64 
   `--  sys-devel/automake-1.16.1-r1  (>=sys-devel/automake-1.16.1) ~amd64 
   `--  sys-devel/automake-1.15.1-r2  (>=sys-devel/automake-1.15.1) amd64 
   `--  sys-devel/autoconf-2.69-r4  (>=sys-devel/autoconf-2.69) amd64 
   `--  sys-devel/libtool-2.4.6-r5  (>=sys-devel/libtool-2.4) ~amd64 
   `--  app-arch/xz-utils-5.2.4-r2  (app-arch/xz-utils) ~amd64 
   `--  sys-apps/sed-4.5  (>=sys-apps/sed-4) amd64 
   `--  dev-util/desktop-file-utils-0.23  (dev-util/desktop-file-utils) amd64 
   `--  x11-misc/shared-mime-info-1.10  (x11-misc/shared-mime-info) amd64 
[ gnome-base/librsvg-2.40.20 stats: packages (26), max depth (1) ]

I had suggested to get a Gentoo prefix for Toolforge, but since it's gotta put all the binaries (including compilers on NFS), it's not a 'loved' idea.

The dependency game might be too painful :(

At some point, I think we will have to embrace custom Docker images but we're not there yet and it will take a while (probably not before we adopt a PaaS solution).

In the meantime and, with the goal of containing any future technical debt, I would like to propose we create a "php72-commtech" image that has all these extras. The advantage would be this is clearly tied to Community Tech and when the time comes to adopt an image build pipeline, we know for sure who is using it (as opposed to adding it to the standard "php72" image today and never being able to remove it because it could be used by who knows how many users). I think this would be a good compromise.

My main goal with this proposal is to give our end users the flexibility they need today with the platform we have today while minimizing future headaches. If that would be acceptable I can work on creating this team-specific image. We should not encourage others to request more specific images if possible though. It should be clear this is an exception for CommTech until we have a proper image build pipeline in place, because creating team-specific image won't scale with our current processes.

Change 480159 merged by jenkins-bot:
[operations/docker-images/toollabs-images@master] php72: add RSVG

https://gerrit.wikimedia.org/r/480159

Leaving ideology aside until we have a proper solution for this and then we can review these images and remove anything we desire.

Image built and pushed to the repository.

# docker run --rm -ti docker-registry.tools.wmflabs.org/toollabs-php72-web rsvg-convert --version
rsvg-convert version 2.40.16

In T151656#4838151, @GTirloni wrote:

In the meantime and, with the goal of containing any future technical debt, I would like to propose we create a "php72-commtech" image that has all these extras. The advantage would be this is clearly tied to Community Tech and when the time comes to adopt an image build pipeline, we know for sure who is using it (as opposed to adding it to the standard "php72" image today and never being able to remove it because it could be used by who knows how many users). I think this would be a good compromise.

My main goal with this proposal is to give our end users the flexibility they need today with the platform we have today while minimizing future headaches. If that would be acceptable I can work on creating this team-specific image. We should not encourage others to request more specific images if possible though. It should be clear this is an exception for CommTech until we have a proper image build pipeline in place, because creating team-specific image won't scale with our current processes.

I think this is a bad route to go down - tools are about well, the tools, not the people behind them (related: cloud VPS projects being about projects, not teams).

Adding rsvg to the main php72 image seems very reasonable to me (I was going to do it in August but didn't because time...) because it's a dependency of MediaWiki, and very highly used in our projects.

@Legoktm I'm sorry, I didn't know it was a dependency and a highly used one. I only saw a request from CommTech to add a package and no other justification other than "we need it".

In any case, where do we draw the line? Say a volunteer wants to add LaTeX to the stretch image.

This ticket is probably the wrong place to have this discussion, but I'd also like to know what the protocol should be — I don't know about latex (although actually that'd be cool to have available to a tool!) but the other day I wanted GraphViz in the php7.2 container and I didn't want to request it because it seemed from this ticket that that's not the way things are going. But maybe it is? I totally understand that the line has to be drawn somewhere, and perhaps it's going to be a matter of waiting for the future point at which custom containers will be supported.

@Jarry1250 : Actually since last week librsvg 2.40.20 is installed on servers, therfore we might should change the title. (Update librsvg to 2.40.20 on toolforge)

In T68672#5110845, @jijiki wrote:

Since last week all servers are using librsvg 2.40.20-3 which fixes some svg rendering issues (and possibly introduces others).

Is still task still relavant? Stretch has 2.40.21 and Buster 2.44.10 these days.