Allowing PortGroups to bump port revision

Joshua Root jmr at macports.org
Sat Jan 13 07:28:41 UTC 2018


On 2018-1-13 13:13 , Clemens Lang wrote:
> Hi,
> 
> On Fri, Jan 12, 2018 at 03:30:50PM -0800, Jeremy Huddleston Sequoia wrote:
>> In https://trac.macports.org/ticket/54744, we've been pondering adding
>> a PortGroup to allow concurrent installation of multiple providers of
>> the OpenSSL API (eg: openssl, libressl, libressl-devel) and allow
>> ports to specify which they are compatible with.
>>
>> It occurred to me that it would be nice if we could update the
>> PortGroup when one of the dependencies changed their dylib id rather
>> than revbumping all ports.  Is this something anyone else has
>> considered?
> 
> I'd love to use this feature for updates of GHC. For every new version
> of GHC, libraries built with it are installed in a new directory and get
> a new ID, which means that I have to find and revbump every haskell port
> with such an update.
> 
> Unfortunately ports are only re-indexed when their mtime changes, so
> while you could just set revision (or epoch, or some other variable) in
> a PortGroup, that would still not lead to those ports getting reindexed.
> 
> We'd have to keep a map from PortGroup to Portfiles that use this
> PortGroup to modify portindex to correctly re-index ports when a
> PortGroup changes; note that this might also take quite long. I can
> imagine changing the GitHub PortGroup would lead to index update times
> of more than 10 minutes. :(

If I understand the problem correctly, it seems like a better solution
would be maintaining a database of linkage. You could then look up which
dylibs a port provides and which ports link against them. The rev-bump
scripting already exists as mentioned earlier. Automated alerts when a
commit causes broken linking could also be done.

We could also consider adding an archive revision. This would just
increase whenever rev-upgrade is needed, and cause the buildbot to build
a new archive. Clients could probably virtually ignore it and just rely
on rev-upgrade finding the broken linking. That way nobody has to
reinstall anything that isn't broken (e.g. if their chosen variants
don't use the changed dylib.)

- Josh


More information about the macports-dev mailing list