On Tue, 26 Aug 2008 15:25:16 -0700 "Robin H. Johnson" <[EMAIL PROTECTED]> 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.