From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KY7JK-0004ZT-Tn for garchives@archives.gentoo.org; Tue, 26 Aug 2008 22:46:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 04B3FE0206; Tue, 26 Aug 2008 22:46:17 +0000 (UTC) Received: from duke.math.cinvestav.mx (duke.math.cinvestav.mx [148.247.14.23]) by pigeon.gentoo.org (Postfix) with ESMTP id C4F5CE0206 for ; Tue, 26 Aug 2008 22:46:16 +0000 (UTC) Received: from xdune.lan (unknown [189.140.143.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by duke.math.cinvestav.mx (Postfix) with ESMTP id D29BC14059 for ; Tue, 26 Aug 2008 17:46:15 -0500 (CDT) Date: Tue, 26 Aug 2008 17:46:15 -0500 From: Yuri Vasilevski To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted Message-ID: <20080826174615.101609c8@xdune.lan> In-Reply-To: <20080826222516.GI30560@curie-int.orbis-terrarum.net> References: <20080826204036.GE30560@curie-int.orbis-terrarum.net> <20080826154107.373c7095@xdune.lan> <20080826205421.GF30560@curie-int.orbis-terrarum.net> <20080826155909.6d2ba7a6@xdune.lan> <20080826214525.GH30560@curie-int.orbis-terrarum.net> <20080826165750.07a3792c@xdune.lan> <20080826222516.GI30560@curie-int.orbis-terrarum.net> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i486-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: b490cc47-8a48-4931-887e-84239e75fbd7 X-Archives-Hash: 2b71b4c0e8ad5b3ecbe8071041451033 On Tue, 26 Aug 2008 15:25:16 -0700 "Robin H. Johnson" wrote: > On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote: > > > Why do you need to identify the changes? Considering that the > > > checksum changes as well, is detecting change not sufficient? (or > > > asking the VCS for what files have changed since your last check > > > time). > > I am writing a tool that creates deb (as in Debian package format) > > based distributions from gentoo packages and that tool encodes the > > CVS revision as part of "debian revision" of the packages. So I > > need this part to be chronologically ordered, as opposed to have > > only the knowledge of whenever the file has changed or not. > I'd call that critically dangerous in missing some changes. > If I have a file in $FILESDIR, and change it, but it has the same > name, there is no commit to the ebuild, and your .debs won't pick up > changes at all. This is usually for cases with compile fixes that > don't need revision bumps at all, but sometimes there are also > changes to scripts. Yes, I know that this will not protect me against changes in a file from ${FILESDIR} nor a change in a file in ${A}, but that was the best way I could think of to make debian source packages (I create as well) as reproducible as possible. For the source packages I create a debian/rules[1] file that basically calls ebuild foo.ebuild with the right options and to compile and then install to a temporary directory and then call some debhelper scripts to turn that directory into a proper .deb package. So from my perspective the .ebuild file can be considered part of the debian/rules files and because of that I really need to keep track of changes in it. And for the rest of files, I bump ( :-D ) another revision counter with each rebuild of the same debian source package version, so until I find some better way to catch changes in any bit of the source (be it the ebuild, files from ${A} or files from ${FILESDIR)/) I still don't have conflicts. > If you're making binary package .debs, I gather that you are grabbing > the (pre|post)(inst|rm) and setup blocks for inclusion? Yes, I certainly do. > That is an interesting use case, and would that would present a > problem with any VCS migration. > - Under SVN, you'd only have the global revision, which might not > uniquely identify the file. > - Bzr doesn't support keyword expansion in any released version. There > are/were plans for it in 1.7, but I haven't seen anything since the > first prototype. > - Hg supports it with an extension: > http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension > But has warnings about why it sucks > http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan > See the 'keyword update intervals' item (mainly having to touch > every file in the repo sometimes). > - Git supports only the $Id$ keyword, and expands it to the SHA1 of > the file, which ends up being a duplicate of the information we have > in the Manifest. I am aware about this problem, and unless this is explicitly taken into consideration on migration, I guess I'll have to keep a local database of "order" of ebuilds as part of the metadata associated with each distribution my tool creates. [1] debian/rules files is a make file that provides the right targets for debian tools call it and generate deb binary packages. So it is kind of the equivalent of .ebuild scripts for debian.