gegl issue when doing rev-update
macportsusers-20171215 at billmail.scconsult.com
Mon Nov 12 16:03:56 UTC 2018
On 12 Nov 2018, at 8:57, Riccardo Mottola via macports-users wrote:
> On 2018-11-09 18:43:56 +0100 Ken Cunningham
> <ken.cunningham.webuse at gmail.com> wrote:
>> openexr was updated a few days ago
>> the new library version is /opt/local/lib/libIlmImf-2_3.24.dylib
>> it looks like gegl (gegl-0.2) is gone now. Not sure where or when it
>> there is gegl-0.3, gegl-.04, and gegl-devel.
>> You should most likely uninstall gegl, and install one of the others.
> This is what I have :
> $ port installed | grep gegl
> gegl @0.2.0-20180218_2+quartz (active)
> gegl-0.4 @0.4.0_0+quartz
> gegl-0.4 @0.4.2_0+quartz
> gegl-0.4 @0.4.6_1+quartz
> gegl-0.4 @0.4.8_0+quartz
> gegl-0.4 @0.4.12_1+quartz
> gegl-0.4 @0.4.12_2+quartz (active)
> how can I try uninstalling gegl-0.2 without causing issues? I notice
> it is the active "gegl" without version suffix.
Which would reflect a port maintenance bug, if you were using a current
version of the ports tree. 'gegl' without a suffix is no longer present
in the ports tree.
> If I try to uninstall gegl:
> $ sudo port uninstall gegl
> Note: It is not recommended to uninstall/deactivate a port that has
> dependents as it breaks the dependents.
> The following ports will break: gimp2 @2.8.22_2
> I wonder if it is correct and ig gimp2 is using gegl-0.4 or generic
> "gegl" and by that the 0.2 version.
It might be. That's an obsolete version of Gimp, so maybe it needs an
obsolete GEGL. That doesn't make much sense if you also have a newer
version of GEGL, since the two are intimately connected and the only
other port that requires GEGL is 'gnome-photos' and it currently
requires 'gegl-0.3' specifically.
If you update to the current version of the 'gimp' port (or of 'gimp2'
if you don't have the 'gimp' meta-port installed) you will get the
latest version of the 'gegl-0.4' port installed as a dependency.
> Is this actually the expected situation? I would have thought I could
> have older versions, but they should be versioned and that only latest
> would have no version.
No, that's not how it works. You cannot rely on the current ports tree
always following that rule in all cases. This is particularly true for
libraries that are being actively developed, because some dependents may
not work with the latest version of the library while others are updated
to require it.
To fix this, you should update your ports tree ('port sync' or 'port
selfupdate') and then 'gimp' (or 'gimp2' if you don't have the 'gimp'
meta-port installed) and 'port reclaim' when finished to clean up any of
the old useless versions.
More information about the macports-users