> I think Michael is thinking: > > I have port 'foo' in macports and it requires a (rather large/complicated) > patch that currently sits in files/ and has to be re-generated every time > upstream releases a new version of 'foo' > > And essentially we're saying "we haven't done anything to make that easier" > (Macports repo move doesn't change how you are dealing with this now). > > While this should be a minority of ports (and all port maintainers should > work to get their patches incorporated upstream whenever possible), it would > be worthwhile in looking at things to make handling this situation easier > (especially if similar projects already have tools to deal with it). It's > also perfectly reasonable to punt on this until after we've settled in after > the repo move. > > -- > Daniel J. Luke
Exactly. I'm looking into what "Git for Windows" does, because this is exactly what they do -- maintain a large set of patches that are release specific and not integrated upstream. And, it's my understanding that MacPorts is basically a pair of (port file: how to compile; patch files: how Mac OS / Xnu / Mach differs from Unix/Linux/Debian). I was under the impression that the switch from SVN to maintain the patch files to Git to maintain the patch files (not the port files) was the issue where you wanted rebases at each upstream release. --- Entertaining minecraft videos http://YouTube.com/keybounce _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
