Hi Scott, Agreed, an explicit version file is my favourite as well. Helps to avoid bogus repo tags and all sorts of other problems ...
Still we should try to take in as much information as possible, no matter how the source code was obtained ... Here's my take on it (open for discussion): "vergen" should look for the "VERSION" file _AND_ the git information and then produce "something" that is fed to the package. What "something" is depends a lot on the platform, RPM vs other Linux package format vs *BSD vs Solaris vs AIX vs ... you get the idea. RPM supports almost arbitrary things in the version (yuk!) but other package managers don't .... If both the "VERSION" file and git repo informations are present the "VERSION" file should take precedence but if the git info has some additional data like "tags and number of commits away", we could at least try to add a comment to the package. If only git or the "VERSION" file information is present then whatever is there should take precedence, however, a comment about the absence of the other would be helpful. Just my two [pennies|cents|kopecks|...] ... Andreas -- Andreas Leibl, RSTC Ltd Registered in England no: 6306790 VAT Registration no: 901 2682 54 Registered Office address: Gifford House, Burton Row, Brent Knoll, Highbridge, TA9 4BX, United Kingdom On 5 Aug 2014, at 19:09, "Scott T. Hardin" <[email protected]> wrote: > > On Aug 5, 2014, at 12:55, Sergei Vyshenski <[email protected]> wrote: > >> Distributions from GH come without .git subdirectory, so I had to >> replace calls for vergen with the appropriate version number. >> Port/package system do not tolerate distributing sources in form of "git >> pull" or such. Only regular tarballs are welcome here. Also in case of >> client-html-mason I had to regenerate ill Manifest. > > I ran into a similar workflow problem while working with the RPM build > process. RPM build prefers extracting the files from a tarball directly. The > %build section then runs Makefile.PL, which doesn't find the data from Git. > As a workaround, I added the file "VERSION" when creating the tarball and > modified Makefile.PL to use this for the OpenXPKI version (e.g.: "0.18.0"), > if found. This could easily be expanded to include the Git tag and commit > hash, if desired. > > > Scott > > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > OpenXPKI-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-devel ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
