On 06/17/2013 07:07 AM, David Sommerseth wrote:
> On 16/06/13 17:31, Akemi Yagi wrote:
>> On Sun, Jun 16, 2013 at 7:52 AM, Yasha Karant <[log in to unmask]> wrote:
>>> I need the current ufraw plugin plus support files for gimp.
>>>
>>> I could find: ufraw-0.19.2-2.fc17.1 rpm
>>>
>>> for Fedora 17, but this will not install into SL 6x . According to the
>>> ufraw URL, the above ufraw release does support the raw digital image
>>> formats we need.
>>>
>>> Yasha Karant
>>
>> NuxRo's repo has ufraw 0.18-2:
>>
>> http://pkgs.org/search/?keyword=ufraw
>>
>> If you need 0.19, try compiling it from the fc17 source. There might
>> be some dependency issue though.
>
> Just what I would suggest as well. Pull down the src.rpm package and do:
>
> $ rpmbuild --rebuild $SRC_RPM
>
> This will be some iterations to get proper -devel packages installed.
> But if you start to need other source packages, then it will be
> considerably harder - as that may break your SL installation if you
> update some commonly shared libraries.
>
>
> --
> kind regards,
>
> David Sommerseth
>
Let me approach this general issue from a different point. None of the
linux systems designs easily enable proper encapsulation and
polymorphism, as the above comment illustrates (that may break your SL
installation if you update some commonly shared libraries, end quote).
Can one build an application (in this case, GIMP "plug in") to use only
static libraries within a unique build tree that does not overlap with
the standard SL installation?
Unless the incompatibility is at the kernel, Xwindows, etc., API level,
then a fully static (in open systems parlance, not .so, but .a
libraries) implementation should work. Such a static image could
require considerably more memory (both RAM for execution as well a mass
storage for the image), but should not interfere with the standard SL
(SL Nx, currently N = 6).
If such a static "isolated" build is possible within SL, are there any
tools/packages/scripts that more easily enable such an approach?
Yasha Karant
|
