On Sep 29, 2014, at 10:59 AM, Daniel J. Luke wrote: > On Sep 28, 2014, at 2:55 AM, Ryan Schmidt wrote: >> >> Moving this code to a portgroup would make it possible for us to fix this >> problem and any other problems that might come up later without having to >> produce a new MacPorts release. > > I think we really should move in the other direction: > > -make releases easier > -less code in portgroups (move as much as possible to base/) > > someone can say "I did foo with macports version x.y.z", it's hard for an > end-user to know "I did foo with macports verison x.y.z and the revision of > portgroup blah that I got in my last portsync which corresponds with rXXXXXX > in your repo"
Sorry for my delay in responding to this. I disagree that we should move as many portgroups as possible into base. Moving the portgroups out of base and into the ports tree years ago has been of great benefit in encouraging the development of portgroups. No matter how agile the release process of base may become, nothing compares to being able to put a file in a directory and having it available to the entire MacPorts userbase in minutes. Conceptually, the portgroups belong with the ports. It has often been necessary to make a change to a portgroup and changes to the ports that use it simultaneously in the same commit; that's not possible when there is a non-automated or delayed release process for base, as there currently is and as there probably needs to continue to be. I don't oppose making base releases easier, however I don't think we want to go as far as we go with the ports tree. We want to have some sort of testbed for base changes before they go to all users. We want developers to be able to run a development version of base before potential problems inconvenience regular users. Another argument against putting all portgroups back in base: When I'm making a change to a portgroup, I don't want to also be responsible for also understanding all other changes that went into base since the last release. All I care about when changing a portgroup is the portgroup and the ports that use it. I'm not against moving *some* portgroups' functionalities into base, such as the compiler_blacklist_versions, conflicts_build and muniversal portgroups. The spirit of the archcheck portgroup is already in base. But portgroups that are closely tied to a particular subset of ports, like language modules, feel like they belong where they currently are. We could even talk about moving support for some build systems into base. Xcode and cmake are certainly popular build systems that aren't going away, and the portgroup haven't needed to change that much recently, so they may be stable enough to be in base. So "PortGroup cmake 1.0" would change to "use_cmake yes" for example. I continue to think that xmkmf/imake support should be moved out of base and into a portgroup. Why should someone trying to read and understand base code have to encounter xmkmf/imake code applicable to only a handful of old ports? Further, the xmkmf/imake support in base is incomplete (doesn't use the right compiler, doesn't use -arch flags, doesn't add the universal variant). I can either leave this aspect of those ports broken, or spend time figuring out what to modify in base to fix this, or I can trivially fix this with a few lines in a portgroup I've already written. I would like to do the latter. I'm trying to make the needed changes to all the ports that use imake and make sure they build before committing this. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
