Reinhard Tartler <[email protected]> writes: > 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.
OK, makes sense so far. >> 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. Glad we agree on something. >> 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' No, the VERSION file, if present, will have exactly the same effect as it currently does: overriding the git-based version tag. > and make 'git describe' override its contents. No, the new file will be a fallback for when git data is unavailable. > Obviously, the 'New file' can't go into master as it would make > identifing the git version used to build the binaries impossible. Why? If built from a git repo, this file will never be used. > 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. WTF? Your packaging repo could continue to carry a VERSION file just like you're doing now. I don't see a difference. I'm suggesting to put the release version in this file, not VERSION, in the master branch. Then builds from a tarball will use this version while builds from a git repo will continue to use whatever "git describe" spits out. One side-effect of this will be that builds from a non-git tree will identify as the latest release rather than UNKNOWN. I don't think this is important. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
