Updating PortGroups Versus Base

[Ryan Schmidt]

On Mar 6, 2013, at 10:56, Jeremy Lavergne wrote:

>>  We're currently implementing a lot of things in PortGroups that
>>  should probably be added to base in some way, and having the
>>  internals around would simplify doing that.

Ah, I see you're quoting from the "deactivate hack in PortfileRecipes?" thread.


> In a way, the PortGroups allow us to avoid making frequent releases, as changes can be implemented temporarily as a PortGroup. That's just a side effect of how we use them, though.
> 
> We have no milestones presently, so our roadmap is rather goalless.
> 
> Perhaps a milestone for the next release can be adding the ability to sanely handle these PortGroup/base ambiguities. Once base can differentiate what it has available (people who have updated) versus what it needs to rely on in the PortGroups (people who haven't updated) yet, then we can cull pieces from PortGroups at the usual two weeks or simply as they increment their PortGroup versions.

I'm not sure I understand. Yes, there are things in portgroups that should be moved to base. But what changes to you think base needs made first in order to allow us to do that? Taking the conflicts_build portgroup as an example, I envisioned that if we move that option to base somewhere, then the entire portgroup would just be wrapped inside an "if {![info exists conflicts_build]}" block. Then, after that new version of base is released, ports can remove the "PortGroup conflicts_build 1.0" line. The portgroup file itself should probably stay around (even if its contents are deleted) for a long time, possibly forever, since deleting it would break any old ports the user has installed -- even ancient inactive ones.


> We also have one high priority ticket ready for a release:
> http://trac.macports.org/query?status=closed&group=resolution&milestone=MacPorts+Future

You're referring to #32542: "Setting configure.compiler to a MacPorts-provided compiler doesn't add dependency automatically". To me that's not even a high-priority issue. Much more pressing for me is 
"#38010: MacPorts should prevent overlinking due to .la files"; I would like to get MacPorts 2.2 out soon for that reason alone; lack of releasing that is basically why I haven't updated icu to version 50.