Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Yuri Vasilevski <yvasilev@gentoo.org>]

On Tue, 26 Aug 2008 15:25:16 -0700
"Robin H. Johnson" <robbat2@gentoo.org> 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.