On Oct 13, 2014, at 6:19 PM, Ryan Schmidt <[email protected]> wrote: > > On Oct 13, 2014, at 5:00 PM, Daniel J. Luke wrote: >> On Oct 13, 2014, at 5:54 PM, Ryan Schmidt wrote: >> >>>> On Oct 10, 2014, at 9:05 AM, Daniel J. Luke wrote: >>>> >>>>> 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. >>>> >>>> right - and I'm saying that that's actually a problem >>>> >>>> 'easy' injection of code into the tree without going through any kind of >>>> release process/review is something we should minimize. >>> >>> Playing devil's advocate for a moment, are you suggesting that we institute >>> a similar release process/review for portfile changes? >> >> we should continue improving base/ (non-root execution, sandboxing, trace >> mode, etc) so that 'rogue' portfiles cannot do damage (or can do limited >> damage) so that this isn't necessary (or is less necessary). > > Sure, and we're already pretty good at that, and will continue to get better. > But if Portfiles cannot do damage,
they still can (currently) > then portgroups, which are merely code included by portfiles, cannot do > damage either. There's no difference in the capabilities of code in a > portgroup vs code in a portfile. portfiles are usually simpler than portgroups (almost by definition). a portfile that looks like a few key-value pairs is a lot easier to trust/validate than something that sources a bunch of tcl from a portgroup. > I also see a problem if a port uses a portgroup, and wants to use two > different ports, at different revisions, that expect different versions of > the portgroup. Is this kind of problem the reason why you're against > portgroups? this is one of the reasons why I find them somewhat problematic, yes. Another way to look at it is that generally the portgroup is unversioned (and an end user doesn't necessarily know which version of a portgroup was used when a particular port was installed). > I do want there to be lots of metadata about ports on the new MacPorts web > site, including information such as results of buildbot builds. If we get to > the point of automating test runs that could be included as well. The web > site could also make that information available to the command line MacPorts > program in some way if we wanted to do that. I think that would be great. If I were writing macports from scratch, I might have 'remote portfiles' be the default, you would ping a portfile server to see what was available, or pull whatever recipe for building a port that you selected. End users could select various criteria that they wanted enforced (only install ports that have been reviewed by a MP committer, only install ports that passed a test suite, only install ports that are GPL compliant, only instal ports that built on the buildbot...). It could be simpler for people to (attempt to) install a port at a particular version/revision too. ... but those additional capabilities are probably of marginal utility for most people, so I don't think that they're reasonable immediate design goals - instead there are clearly some areas where we can and should continue to improve. >>> Because if so, that would be stifling, and if not, then I don't see it >>> working very well, since it's previous been very convenient to be able to >>> make changes in portgroups simultaneously with changes in ports. Losing >>> that ability will make working with portgroup more difficult. >> >> it's not all or nothing, but I think we should generally push more code into >> base/ (especially after an portgroup has matured somewhat) rather than >> pushing for more and more code out of base/ > > Even for decade-old build systems like imake that are only used by a handful > of ports? yes, for as long as we wanted to support imake builds > That would for me be the definition of special-case code that doesn't belong > in base. most of base could be construed as special-case code ;-) > The other thing I really like about portgroups is that all code related to a > particular thing is contained within a single file. When I want to > investigate a feature in base, I have to first use grep to figure out what > file(s) the code is in, and it's usually spread out all over the place. In > the case of imake support, it's only in two files, portconfigure.tcl and > portutil.tcl, but that first file is 800 lines long and, like most of base, > hard to read, for someone otherwise only accustomed to reading portfiles. > Having all the imake- (or whatever-) related code in a single short portgroup > file is much easier to understand and change. it seems like that is a problem with base/ and our dev documentation (or lack of) which it would make sense to fix rather than work around it in that way. It would probably even be possible/reasonable to keep the portgroup implementation the same, and just have base source (some?) from a base install location instead of (or in addition to) the ports tree. -- Daniel J. Luke +========================================================+ | *---------------- [email protected] ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
