Package Details: resvg 0.44.0-1

Git Clone URL: https://aur.archlinux.org/resvg.git (read-only, click to copy)
Package Base: resvg
Description: SVG rendering library and CLI
Upstream URL: https://github.com/RazrFalcon/resvg
Licenses: MPL2
Submitter: flying-sheep
Maintainer: flying-sheep
Last Packager: flying-sheep
Votes: 24
Popularity: 0.057050
First Submitted: 2018-05-24 11:10 (UTC)
Last Updated: 2024-10-19 15:54 (UTC)

Dependencies (13)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4

flying-sheep commented on 2019-02-16 13:50 (UTC)

OK done! The packages exist

kubrick commented on 2019-02-12 15:21 (UTC)

Hi,

So, I have no particular bias against "kio and friends".

It's just that I use resvg as a build dependency to build other packages and I expect that this is going to become a more and more widespread use case (to make png icons out of svgs for GUI apps or themes).

As a build dependency, it really sucks to have to pull all these dependencies that are of no use whatsoever for the job at hand.

So what I would do, is have 3 different aur packages resvg, “resvg-cairo”, “resvg-qt” with the last two depending on the first one. When resvg hits the community or extra repos (as I hope it will eventually), then making one single split package will make sense.

That is my opinion at least, thanks :-)

F

flying-sheep commented on 2019-02-12 09:35 (UTC) (edited on 2019-02-12 09:46 (UTC) by flying-sheep)

Hi! I like your idea of forking off minimalistic alternative packages: “resvg-cairo” and “resvg-qt” would both specify provides=(resvg) and have a hard dependency on either Cairo or Qt, and “resvg” would stay like this package is now, with all components built and optional deps on runtime components. Do you think that makes sense?

The reason why I’m hesitant to split off individual parts is that this package already contains a few largely disconnected parts: A shared library with C headers, a SVG renderer, a SVG simplifier, a SVG viewer and, yes, the thumbnailer. One backend depends on Qt, the other on Cairo. Why should the thumbnailer be treated as a stepchild while the rest also depends on a bunch of libraries coming from different worlds?

Finally, I don’t really understand your dislike for kio and friends here. KDE Frameworks partly are libraries for headless tools. It’s time more CLI scripts start depending on KF5, they’re really good modular libraries. Just view them as a bunch of build dependencies like cairo and zlib. You can remove them after building. Or you can use the extra-x86_64-build script from devtools!

kubrick commented on 2019-02-09 09:05 (UTC)

Hi @flying-sheep,

Thank you but no (if we can avoid it), kio pulls 33 dependencies on my system, all the KDE stuff that I have no use for. The whole point of resvg is that it's a headless command line tool, it would be a shame to make it depend on GUI stuff.

I would really suggest to split the package into resvg, resvg-cairo or gtk, resvg-qt or kde.

F.

flying-sheep commented on 2019-02-08 16:24 (UTC)

Hey! I think it just needs some frameworks to compile properly. I added kio to the makedeps, I hope it builds now!

kubrick commented on 2019-02-08 14:25 (UTC)

Hi,

Building the kde-dolphin-thumbnailer part fails for people who don't have KDE installed, can you make it conditional or make it a separate package?

actionless commented on 2019-01-11 19:26 (UTC)

also see @alfunx comment here: https://aur.archlinux.org/packages/resvg-git/

flying-sheep commented on 2018-12-18 16:38 (UTC)

Good point! I’m only building the docs for resvg-capi now.

actionless commented on 2018-12-16 21:45 (UTC)

hi! are you sure it's a good idea to ship in a package docs for each of the build dependencies? those docs alone are about 37 MiB. i would suggest shipping the docs only for resvg itself.

« First ‹ Previous 1 2 3 4