> On Jan 12, 2018, at 5:21 PM, René J.V. Bertin <[email protected]> wrote: > > On Friday January 12 2018 15:30:50 Jeremy Huddleston Sequoia wrote: > >> 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 don't think I really understand what you mean, could you give an example? > > If you mean something akin to setting the `version` in a PortGroup, this > doesn't always work reliably. I have such a PG and it seems there are always > some ports that don't show up in `port outdated` after I bump the version > (presumably because PortIndex can fail to detect that a port imports certain > PGs). > > If you do think of setting a revision in the PortGroup: how do you propose > coping with the fact that dependents may set their own revision, typically > after including the PortGroup?
My initial thought was that it would need support in base and that a port's revision would be the sum of its base revision and the revision of all of its PortGroups. Unfortunately, that would get ugly if a portgroup were removed. It would also be confusing to determine exactly what revision was being used in a bug report. My next thought was that we could add another version field for PortGroup revision. We could use the highest value set amongst all the port's groups when comparing versions. That still has the downside of causing problems if a PortGroup is removed. I suspect many such cases would come with a revbump anyways, so that's probably not too big of a concern.
