Ports updated without maintainer notification?

Jason Liu jasonliu at umich.edu
Sat May 8 19:26:38 UTC 2021


> Did you also update all the other outdated ports on your ‘local’ machine,
> or did you just cherry-pick the updated osl from the current master ?
>

>
If so it is really not a good idea to do that, as it means, as appears
> above, you could get an updated binary tarball install that was built
> against another updated port you do not have.
>

I have a cron job (actually a launchd job) that runs port selfupdate and port
upgrade outdated every night on my machine. I did cherry-pick the updated
osl portfile from the current master in git, but only because I noticed
that the portfile had changed in the git tree but the updated ports weren't
showing up as being outdated.

You should *always* keep all your ports updated and consistent.
>
> if you run
>
> > sudo port -d sync
> > sudo port update outdated
>
> does that help >
>

Running port -d sync results in the updated ports now showing up in the
list of outdated ports. I was under the impression that port
selfupdate ran port
sync as a part of the self-update process? Or am I mistaken, and port sync
needs to be added to my nightly script?

Just finally to note, there is nothing wrong with the current osl builds,
> they are available (apart from arm) down to 10.9
>

It's not the individual libraries that I'm worried about. It's the fact
that these libraries are dependencies for my Blender port. Blender
typically uses slightly outdated versions of all of its dependent
libraries. Very complex libraries are a particular risk. For example,
trying to use the newest version of usd is causing blender builds to fail
on my machine. I remember a time when ports with lots of dependencies, such
as gimp, could be broken for weeks at a time, because updates to one or
more of its dependencies was causing gimp builds to fail. Admittedly, this
was an experience from a decade ago, but it did leave a lasting impression.

Is there some way that I can signal not to update certain libraries without
verifying against blender? Should I leave some sort of warning comment in
the portfiles?

-- 
Jason Liu


On Fri, May 7, 2021 at 12:15 PM Christopher Jones <jonesc at hep.phy.cam.ac.uk>
wrote:

>
> OSL in particular appears to be a problem on my machine. I've copied the
> newer version of the portfile directly to my local machine, and tried to
> build it, but it's failing to build because osl is indirectly dependent on
> opencolorio (by way of openimageio), and apparently there's a new problem
> with either opencolorio or openimageio:
>
> :info:build dyld: Symbol not found:
> __ZN4YAML6detail9node_data12empty_scalarE
> :info:build   Referenced from: /opt/local/lib/libOpenColorIO.1.dylib
> :info:build   Expected in: /opt/local/lib/libyaml-cpp.0.6.dylib
> :info:build  in /opt/local/lib/libOpenColorIO.1.dylib
> :info:build /bin/sh: line 1: 34490 Trace/BPT trap: 5
> :info: build
> opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/build/bin/oslc
> -q
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
> /opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders/emitter.osl
> -o
> /opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/build/src/shaders/emitter.oso
>
>
>
> Did you also update all the other outdated ports on your ‘local’ machine,
> or did you just cherry-pick the updated osl from the current master ?
>
> If so it is really not a good idea to do that, as it means, as appears
> above, you could get an updated binary tarball install that was built
> against another updated port you do not have.
>
> You should *always* keep all your ports updated and consistent.
>
> if you run
>
> > sudo port -d sync
> > sudo port update outdated
>
> does that help >
>
> Just finally to note, there is nothing wrong with the current osl builds,
> they are available (apart from arm) down to 10.9
>
> https://ports.macports.org/port/osl/summary
>
> Chris
>
>
> --
> Jason Liu
>
>
> On Fri, May 7, 2021 at 7:32 AM Ryan Schmidt <ryandesign at macports.org>
> wrote:
>
>>
>>
>> On May 7, 2021, at 01:59, Jason Liu wrote:
>>
>> > I've run across a situation that has left me confused. I started
>> updating some of the portfiles for which I'm the maintainer, and then I
>> noticed that the portfiles seem to have already been updated in git.
>> However, I can't find any PRs for such an update, and I was never notified
>> that the ports for which I'm the maintainer was getting updated... usually,
>> if someone submits a PR for a portfile for which I'm the maintainer, I get
>> a notification through GitHub.
>>
>> If your ports are marked openmaintainer, that gives permission to others
>> to make minor modifications to your ports without notifying you. Not all
>> changes happen via PRs; some are committed directly to master.
>>
>> If there is an urgent issue that needs to be fixed in a port, someone
>> else might make that fix, even if the port is not marked openmaintainer.
>>
>> If you let us know specifically which ports, we could take a look.
>>
>>
>> > In addition, I have run a "port selfupdate" on my machine, and yet the
>> MacPorts on my machine isn't seeing the new version of the port. Is
>> something broken, either on my machine, or on GitHub?
>>
>> If your MacPorts is configured to get ports via rsync, it can take an
>> hour for changes to propagate from git to the main rsync server, and up to
>> a day longer for changes to propagate from there to other rsync mirrors.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20210508/2b07367c/attachment.htm>


More information about the macports-dev mailing list