From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23324 invoked by alias); 29 Jan 2014 17:07:24 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 23285 invoked by uid 89); 29 Jan 2014 17:07:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: northrend.tastycake.net Received: from northrend.tastycake.net (HELO northrend.tastycake.net) (212.13.201.165) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 29 Jan 2014 17:07:22 +0000 Received: from adam by northrend.tastycake.net with local (Exim 4.80) (envelope-from ) id 1W8Ybf-0006NY-OG for cygwin-apps@cygwin.com; Wed, 29 Jan 2014 17:07:19 +0000 Date: Wed, 29 Jan 2014 17:07:00 -0000 From: Adam Dinwoodie To: cygwin-apps@cygwin.com Subject: Re: [ITA] Git et al Message-ID: <20140129170719.GA20623@tastycake.net> References: <52D45B64.4000403@redhat.com> <52E277DC.9050502@redhat.com> <20140129115302.GA11319@tastycake.net> <52E93243.8040106@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52E93243.8040106@users.sourceforge.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00087.txt.bz2 On Wed, Jan 29, 2014 at 10:54:27AM -0600, Yaakov (Cygwin/X) wrote: > On 2014-01-29 05:53, Adam Dinwoodie wrote: > >Thinking about it, my build and packages take Yaakov's work over at > >Cygwin Ports to split the Git packages (at the moment, git-cvs is part > >of the main git package, for example, while my build separates it out). > >I know there have been debates about this in the past; is there > >currently any guideline about the best way to manage such package > >splits? > > I'm not sure to what debates you are referring, but the point of the > split was to provide correct dependencies while isolating those to > the components that actually need them. This was already done with > the more obvious tcl-tk dependency of gitk and git-gui, but my > packages took it a step further. So, for example, git-svn actually > requires subversion-perl, but subversion is not small and not all > git users are going to want that just in order to use git. I seem to recall there being some discussion (I can't remember the specific cases) about whether it would be sensible to have, for at least the first release after a split, all the new packages depending on the thinned down base one. As an example, someone using git-cvs currently would only have the git package. If we list git-cvs as a requirement for the new git package, when they upgrade git they'll automatically get git-cvs and won't lose any functionality. The following update can lose the git-cvs requirement, giving the full advantage of the separated packages. I think this makes things a bit more user friendly, at least for folk who need the separated-out packages and who update their Cygwin setup frequently, at the expense of postponing a lot of the advantage of those separated out packages.