keeping software forks under MacPorts repo?

[Ryan Schmidt]

On Nov 9, 2019, at 10:54, Ken Cunningham wrote:

> In #57751 Michael and I have been talking about how keeping up the patchset for qt4 would probably be easier with our own fork of it, with our patches added on.
> 
> QT4 has a github repo here <https://github.com/qt/qt> and we could fork that to MacPorts repo, and add our patches on there. Then we could draw from that repo for builds instead of the way we do it now. We both think this would be easier.
> 
> I see Haiku already does that exact thing for some of their ports.
> 
> Hopefully leaving aside a discussion about older systems / lots of patches/ etc for the moment, is there any interest in having these occasional forks under MacPorts github repo?

That seems reasonable to me for projects like qt4 and llvm where we have extensive patches. 

But for many projects (is Qt one of them?) upstream produces release tarballs that contain generated files (like configure scripts) that aren't in the repo. We would either have to produce those tarballs ourselves, or else make the ports use ./autogen.sh or equivalent. 


> Otherwise either Michael or I can do it ourselves, but that might have access issues someday...
> 
> On a similar note, we have a couple of ports in the same boat (llvm*, for example). In those, Jeremy has his own fork with our patches, and uses a script to generate the patchsets — but that’s tricky, because I can’t access his repo very easily, so my patches are “extras” to his…

Back when Jeremy was maintaining these ports more actively, llvm used to use a Subversion repository. I suppose Jeremy maintained his fork using git-svn. Now that they've migrated to git, keeping a fork of their repo should be easier. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20191109/151c881a/attachment-0001.html>