Bugzilla Bug 100386

The Inkscape 0.42 release is complete, and packages are now available:

https://sourceforge.net/project/showfiles.php?group_id=93438

Lots of new features and fixes since 0.41.  :-)

Reproducible: Always
Steps to Reproduce:
1.
2.
3.



Expected Results:  
Upgrade portage to supply inkscape 0.42

If there are any problems with this release, please report them here and/or at
the Inkscape bug tracker.  

FYI, we are shooting for getting 0.43 out within a month or two.

Created an attachment (id=64402) [edit]
inkscape-0.42.ebuild

Ebuild attached.  Tested on amd64 with no problems.

Tested on x86 (P4 Xeon's) and works great!

Some additional optional requirements to get the python scripting to work too -
found this in the Gentoo forum posted by Matteo Azzali:

<<<<<<<<<<<<<<<<<<<<< Quoted from Forum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Just to warn in advance.
Compile (emerge) inkscape 0.42 will not require them,
but they'll be required to run inkscape scripts (very good new feature)
so there'll be need for libxml-xql-perl (requiring perl)
and python-xml (requiring python).
http://packages.debian.org/unstable/source/libxml-xql-perl
http://pyxml.sourceforge.net/
Since these packages aren't in portage
at the moment, I just wanted to warn (if someone post a link to a
"howto create ebuilds" tutorial I can also try to write down....)

bit more docs:
http://www.inkscape.org/cgi-bin/wiki.pl?GettingExtensionsWorking
http://www.inkscape.org/cgi-bin/wiki.pl?GettingEffectsWorking

P.S.:Since scripting will need big dependancies and is not compile-needed,
maybe a specific use flag will be useful too.
<<<<<<<<<<<<<<<<<<<<< End Quote >>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Thought some of you might find that interesting - looking forward to testing the
ebuild.

I added an ebuild for XML-XQL as per the comment above, pyxml is already in
portage.  I modified to ebuild to reflect this.

Created an attachment (id=64408) [edit]
inkscape-0.42.ebuild

Would it be possible to break-up the operation of the plugin USE flag into,
perhaps, plugin and scripting?

This would allow installation of the scripting dependencies separately from the
other plugin elements.

I personally would make use of the Perl and Python scripting features but have
no need for Dia, skencil etc.

Regards,
Neil Darlow

*** Bug 100505 has been marked as a duplicate of this bug. ***

Good idea to break up the USE flag, we expect to see growth in the use of
scripting over the next few releases, and the Gentoo package needs a smarter way
of handling this, so that if someone doesn't need every extension available,
they don't have to install a huge amount of secondary packages.

Bryce

Please re-attach the ebuild as text/plain.

(In reply to comment #9)
> Please re-attach the ebuild as text/plain.

My bad.  Sorry for the spam :/

Created an attachment (id=64521) [edit]
inkscape-0.42.ebuild

inkscape 0.42 ebuild. New USE flag 'scripting', with conditions on 'perl' and
'python'

scripting? ( python? ( dev-python/pyxml )
	     perl? ( dev-perl/XML-XQL ) )

Are the changes you made to separate the plugins from the scripting actually
going to change the way that Inkscape is built?

For example, lets say that I already have pyxml installed, but don't want
scripting support to be available in Inkscape.  Will setting USE="-scripting"
actually *force* Inkscape to be built without scripting even if pyxml is available?

You may also want to consider reassigning the bug to zypher@gentoo.org since he
is the specific maintainer for this package (as per package metadata).

I should explain something regarding "effects" and "scripting", as I just
realized it could lead to some confusion from a packaging standpoint.

From a packaging perspective, effects (also sometimes called extensions) and
scripting are two completely different, unrelated things.

Effects are (generally) external programs that are exec'd by Inkscape and could
be written in any language, including Python, Perl, Java, C/C++, etc. etc.  They
are handed some portion of the SVG document (usually the current selection),
allowed to make whatever alternations they desire, and then return the changed
SVG to Inkscape.  Effects are a relatively new feature but already a number of
extensions have been contributed and are available in the program.

Separate from this, Inkscape also has scripting support.  This literally means
that a Python interpreter and a Perl interpreter can be compiled into the
application.  This allows you to type in scripts into a dialog in Inkscape and
have them be interpreted and (in theory) operate on the document directly. 
However, this is still a very early-in-development feature and is not very
widely used except for development/experimentation purposes.

Anyway, I just wanted to clarify this in case people noticed the --with-perl and
--with-python options in the configure script; those flags are for the script
interpreters, not for the Effects mechanism.  Also, in this thread where people
(including myself) have spoken about 'scripting', we really were (mostly)
talking about the 'Effects' feature.

Also, I think it may be worth naming the USE flag 'effects' rather than
'scripting', to avoid future confusion.  Possibly the scripting features can be
turned on/off via the normal gentoo 'perl' and 'python' USE flags?

how about this solution:

* 'perl' and 'python' use flag enabling python and perl support at compile time
* 'effects' use flag, who implies a dependency on pyxml (if python use flag is
enabled) and/or on XML-XQL (if perl flag is enabled)

This means simply renaming the 'scripting' flag in my ebuild. 

works great on my pentium 4 system :)

That sounds good, however it's not necessary to make the effects conditional   
on the perl or python scripting, since those things are completely orthogonal.    
I.e., the effects will work regardless of whether you specify --with-perl or   
--with-python for compile.  Thus I think you can simplify to this:  
   
* 'perl' and 'python' use flag enabling internal python and perl support at 
compile time  
* 'effects' use flag, who implies a dependency on pyxml and on XML-XQL  
 
  

Works fine on my ancient Athlon machine (CFLAGS="-march=athlon -O2 -pipe").

Created an attachment (id=64646) [edit]
inkscape-0.42.ebuild

changes to reflect comment 16

Btw, why don't you use the ebuild function 'use_enable' for the 'mmx' flag, or
'use_with' for the 'bonobo', 'inkjar', 'gnome', ... flags like you did for the
'spell' flag? This would allow to keep the ebuild unmodified even if the
inkscape people change the default autoconf setting for one of these options.

Commited to portage ebuild from Comment #18. Thanks for help.

As 0.42 has several major bugs (such as line width not working), this bug
#100386 should be reopened (or marked upstream?), the ebuild should rather not
got into portage until 0.42.1 is out. An announcement for this has already been
made on www.inkscape.org

btw, the whole src_unpack() section of the ebuild is now useless and should be
removed from the final ebuild

Created an attachment (id=64969) [edit]
Cleaner inkscape-0.42.ebuild

Here is a cleaner ebuild.  It uses use_with and use_enable, removes the
src_unpack function, and also moved the G2CONF line into the src_compile
function so it isn't processed every time the ebuild is.

Created an attachment (id=64970) [edit]
Fixed clean inkscape-0.42.ebuild

Whoops, use the gnome2.eclass config function.

(In reply to comment #23)
> Created an attachment (id=64969) [edit]
> Cleaner inkscape-0.42.ebuild
> 
> Here is a cleaner ebuild.  It uses use_with and use_enable, removes the
> src_unpack function, and also moved the G2CONF line into the src_compile
> function so it isn't processed every time the ebuild is.

Very nice.  You beat me to it.  But I was just going to wait for 0.42.1.