Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 579390 - Move perl based extensions to sub package
Summary: Move perl based extensions to sub package
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: inkscape
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: depchain
TreeView+ depends on / blocked
 
Reported: 2010-04-04 21:57 UTC by Peter Robinson
Modified: 2015-02-12 15:35 UTC (History)
4 users (show)

Fixed In Version: inkscape-0.91-3.fc23
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-12 15:35:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Peter Robinson 2010-04-04 21:57:07 UTC
There are a number of extensions written in perl. It would be nice if these could be moved to a -perl package so the main inkscape package doesn't need to depend on perl. This would be very useful in environments with a small amount of space such as the OLPC and the design Spin livecd where space is at a premium.

As far as I can tell its just the following 4 extensions:

/usr/share/inkscape/extensions/embed_raster_in_svg.pl
/usr/share/inkscape/extensions/ill2svg.pl
/usr/share/inkscape/extensions/outline2svg.pl
/usr/share/inkscape/extensions/txt2svg.pl

Comment 1 Peter Robinson 2010-05-29 22:15:11 UTC
ping? Any issues if I push a change for this to put the extensions in a -perl sub package?

Comment 2 Lubomir Rintel 2010-05-31 08:07:19 UTC
Peter, sorry for no reply. I am hesitant to split the package in separate packages. There are numerous modules in perl and python and lots of them even need more external programs (such as convertors). Maybe a more sane way to do that would be to keep it all in a single package, and don't drag in dependencies such as perl, but request it on demand via packagekit. Inkscape already has xml descriptions for the plugins, that could probably be used to keep track of dependencies.

What do you think?

Does time push you here? In case yes, I'll accept your changes, but would like to review/discuss them first. Do you split core inkscape into a separate package (e.g "inkscape-core") and make the main package depend on core and plugins? It might be a good idea to do that in order not to break user installations.

Thank you in advance

Comment 3 Peter Robinson 2010-05-31 10:55:21 UTC
(In reply to comment #2)
> Peter, sorry for no reply. I am hesitant to split the package in separate
> packages. There are numerous modules in perl and python and lots of them even
> need more external programs (such as convertors). Maybe a more sane way to do
> that would be to keep it all in a single package, and don't drag in
> dependencies such as perl, but request it on demand via packagekit. Inkscape
> already has xml descriptions for the plugins, that could probably be used to
> keep track of dependencies.

I don't see the python plugins as an issue as there's so many other core dependencies that require it (yum for example) so its guaranteed to be around. Perl on the other case is not and there's only the 4 listed above that are perl based. Also the packaging guidelines don't allow you to suppress dependencies. Evolution pushed their perl plugins into a -perl sub package.

> Does time push you here? In case yes, I'll accept your changes, but would like
> to review/discuss them first. Do you split core inkscape into a separate
> package (e.g "inkscape-core") and make the main package depend on core and
> plugins? It might be a good idea to do that in order not to break user
> installations.

It would be useful to have before F-11 closes out for OLPC. I would definitely like it for F-14 as it will allow us to drop perl deps entirely from the Design spin.

In splitting it out into -core and -plugins-python and -plugins-perl with the original package being a holder package that pulls all in might be OK but it looks like a bit of overkill for 4 perl extensions.

Comment 4 Bug Zapper 2010-07-30 11:14:46 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Peter Robinson 2010-08-04 10:15:27 UTC
Ping. What's the status of this?

Comment 6 Fedora Admin XMLRPC Client 2012-10-03 17:38:06 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Gwyn Ciesla 2012-10-04 14:34:14 UTC
New maintainer, is this still desired?

Comment 8 Peter Robinson 2012-10-04 14:55:27 UTC
Yes please!

Comment 9 Gwyn Ciesla 2012-10-04 14:56:29 UTC
Rawhide only, or f18?  Or more?

Comment 10 Peter Robinson 2012-10-04 15:03:43 UTC
F-18+ would be great. 

On the OLPC images that we ship with inkscape it's the only dependency we have on perl which adds 80+mb (from memory) to the installed image. This is quite a bit of space on the XO-1 where we only have 1Gb of storage so to make those plugins a separate sub package the we can opt in for would save us a fair amount of space.

Comment 11 Gwyn Ciesla 2012-10-04 16:38:46 UTC
I tried it, and the main package still requires perl modules.  I'll keep hacking on it.

Comment 12 Gwyn Ciesla 2012-10-05 11:51:46 UTC
I moved the .pm and a few other things over to the subpackage, and that took care of the perl modules, but /usr/bin/inkscape still links to libperl.so, so the main rpm still requires libperl.so().  I don't think this is possible.

Comment 13 Peter Robinson 2015-02-12 15:35:11 UTC
It seems 0.91 removes the requirement for libperl :)


Note You need to log in before you can comment on or make changes to this bug.