From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Limpach Subject: Re: debian python-install.patch (3 of 5) Date: Mon, 7 Feb 2005 00:47:05 +0100 Message-ID: <3d8eece2050206154747d06a9f@mail.gmail.com> References: <200502061849.54752.maw48@cl.cam.ac.uk> Reply-To: Christian.Limpach@cl.cam.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In-Reply-To: <200502061849.54752.maw48@cl.cam.ac.uk> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Mark Williamson Cc: xen-devel@lists.sourceforge.net, Adam Heath , Ian Pratt , "Keir.Fraser@cl.cam.ac.uk" , "ian.pratt@cl.cam.ac.uk" List-Id: xen-devel@lists.xenproject.org On Sun, 6 Feb 2005 18:49:54 +0000, Mark Williamson wrote: > > debian/changelog changes with each upload(version, changelog entry, and > > timestamp). > > > > Don't get me wrong, I am not trying to keep the debian stuff to myself. > > It's just difficult to integrate with upstream(any upstream, not just xen). > > OK, makes sense. If it's going to cause trouble, perhaps you could maintain > the Debian build system for the "real" packages separately but supply > snapshots to check in every so often? I agree it's not really ideal. I really don't see the point of including the debian build support in the bk repository. It's just as easy for anybody who wants to build updated packages to apt-get source the debian build infrastructure and then make that use an updated source tarball. Maybe the debian build support could have an option to point it at a local bk tree instead of using a source tarball. christian ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl