> On Jun 13, 2015, at 6:58 PM, Alexander Hansen <alexanderk.han...@gmail.com> > wrote: > > >> On Jun 10, 2015, at 15:33, Alexander Hansen <alexanderk.han...@gmail.com> >> wrote: >> >> >>> On Jun 10, 2015, at 15:25, Daniel Johnson <daniel.johnso...@gmail.com> >>> wrote: >>> >>> >>>> On Jun 10, 2015, at 5:44 PM, Alexander Hansen >>>> <alexanderk.han...@gmail.com> wrote: >>>> >>>>> >>>>> On Jun 10, 2015, at 09:53, Alexander Hansen <alexanderk.han...@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> On Jun 10, 2015, at 09:50, Daniel Macks <dma...@netspace.org> wrote: >>>>>> >>>>>> On Wed, 10 Jun 2015 09:34:05 -0700, Alexander Hansen >>>>>> <alexanderk.han...@gmail.com> wrote: >>>>>> No surprise there. :-) >>>>>>> >>>>>>> I was going to initialize the 10.9-libc++ distribution, but then I >>>>>>> got to thinking about whether it might not be a bad plan to use a cvs >>>>>>> import of the 10.7 tree and then rename the directory, so that we can >>>>>>> preserve the history. >>>>>>> >>>>>>> Thoughts? >>>>>> >>>>>> I do not support making a new distro subdir by simply cloning the old. >>>>>> This is a great chance to prune out lots of old crap that doesn't >>>>>> build, stop relying on system hacks like X11 symlink, stop carrying >>>>>> forward -shlibs stub packages from old libversions, etc. However, >>>>>> cloning the old into a holding-pen in git (preserving history) and then >>>>>> using that for selective manual moving into the live distro still >>>>>> within git gives us history linkage. New dist would essentially be a >>>>>> fork or branch. >>>>>> >>>>>> dan >>>>>> >>>>>> -- >>>>>> Daniel Macks >>>>>> dma...@netspace.org >>>>>> >>>>>> >>>>> >>>>> Sure, that makes sense. >>>> >>>> Well, maybe. ;-) I’m not exactly sure about how this would be >>>> implemented, since I believe the selfupdate-git code only pulls from >>>> master. Perhaps we’d have to tweak that during the development phase, and >>>> have the to-be processed stuff be in a non-master branch. >>> >>> That can easily be changed in SelfUpdate/git.pm. You’d have to change the >>> repo from my mirror to the official one anyway. There is another issue >>> though. If we make a new repo now for 10.9+, it will quickly diverge from >>> the existing one. It won’t be easy to merge them later and could become a >>> bit of a nightmare for maintainers. What is the plan for distros going >>> forward? Are we just going to freeze <=10.7 and leave them in cvs while >>> 10.9+ goes to git? If so, we need to do that now before adding distros or >>> we’re in for headaches later. We’re going to have to decide this before >>> doing anything else. >>> >>> Daniel >>> >> >> Yeah, good question. >> >> My initial thought was to keep everything in CVS until 10.11 is released, >> while we clean up the new 10.9-libc++ tree and then switch 10.9 and later >> over to git at the same time as EOL’ing 10.7 and 10.8. That might not be >> the best way to go, though. >> -- >> Alexander Hansen, Ph.D. >> Fink User Liaison >> > > Thinking further, it might be best not to get cute and just set up a > 10.9-libc++ distribution in CVS, and then do the git migration after we club > all of the packages that won’t work or don’t want on ElCaveman. >
Yeah, that would be safest for now. It could be a bit much to make the new dist AND switch VCS at the same time. Best to start with a known non-broken state. :) Daniel
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------
_______________________________________________ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
