On Sun, Jun 19, 2011 at 16:30:35 (CEST), Måns Rullgård wrote: [...]
>> >> As a compromise, let me bring up a variant of a proposal I made earlier >> this month: >> >> - tag the branchpoint 'b0.7' (b == branchpoint) >> - create a new branch 'release/0.7' >> - commit the VERSION and RELEASE files to this branch >> - tag the first release as 'v0.7' (v == version) > > It would help if you could describe what you need for you packaging > process. The Libav package is (team) maintained in a 'special' git repository that imports libav tarballs instead of tracking commits in our libav master repository. This way, the same workflow can be applied to any package, including upstreams that use some other VCS or tarballs only. The exact workflow is documented in the git-buildpackage manual [1]. [1] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html#GBP.REPOSITORY The relevant consequence for this discussion is that in this packaging tree, 'git describe' does not produce the same output as it would in the libav master repository, but rather something like: 'debian/4%0.7_rc1-1'. > My best guess is that you need to override the version that > would otherwise be reported with a debian-style version number, and that > you want to build from a git repo so there has to be a way to override > the "git describe" version. Indeed, currently the /usr/bin/ffmpeg binary shipped by the Ubuntu package produces something like this: FFmpeg version 0.6.2-4:0.6.2-1ubuntu1, Copyright (c) 2000-2010 the Libav developers The first '0.6.2' part is copied verbatim from the VERSION file, the next part is copied from debian/changelog as passed as --extra-version flag to configure. This way the binary produces both upstream and packaging version identifiers. This is a property that we want to maintain. I'm pretty sure that other distros maintain packages in a similar way. > The version.sh script currently uses this priority: > > 1. VERSION file > 2. git describe > 3. UNKNOWN Correct. The released tarballs contain VERSION files, and thus override whatever `git describe` would produce. > Would it work for you if we added another file searched after "git > describe", in which we'd put the release version? The order would > then be this: > > 1. VERSION > 2. git describe > 3. New file > 4. UNKNOWN Now this puzzles me. You're essentially renaming VERSION to 'New file' and make 'git describe' override its contents. Obviously, the 'New file' can't go into master as it would make identifing the git version used to build the binaries impossible. For packaging purposes, the new VERSION file could for example be copied over from 'New file' at build time to get the old behavior back. This seems to me pretty cumbersome, requires documentation (where?), and I don't really see the benefit over the old behavior. Please elaborate what specific problem the introduction of 'New file' would fix. TBH, I'd rather propose to introduce a '--version-identifier' switch to configure, and change version.sh's priority to this: 1. whatever --version-identifier was passed 2. git describe 3. VERSION 4. UNKNOWN This, however, would make the produced binaries rely solely on the version identifier by the packaging and would drop the (admittedly redundant) 'upstream' version identifier. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
