No, I create a tarball and use this to create a rpm package in a clean mock chroot. Among other things this tests the full build from source, tests the dist target, and verifies all the dependencies. These snapshot packages get tested by people using the Hugin snapshots, so there are no surprises when the final release goes into fedora.
I can run `make dist` in a different directory using vpath, but it will still do a full build of the binaries even though they don't go in the dist target, this seems unnecessary. The version labelling in the tarball name is fine if that is how you want to do it, the problem is that the tarball also includes a directory with this name. i.e. I can download the 'enblend-enfuse-4.0.tar.gz' file from sourceforge, but if I extract the files it creates a directory called 'enblend-enfuse-4.0-753b534c819d' rather than the expected 'enblend-enfuse-4.0'. If you plan to change this string to (e.g.) 'rc3', then the result will be that the final 4.1 release tarball will contain a directory called 'enblend-4.1rc3' - Unless you change the string after the final release candidate, but usual practice is that the final release tarball is byte- for-byte identical to the final release candidate. Hope this makes sense. I can cope with these things since I'm going to package enblend whatever, but if the source behaves in a 'normal' way then it vastly increases the chances of enblend getting into all the Linux/BSD distributions promptly. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1052231 Title: info and man pages in mercurial Status in Enblend: New Bug description: Hi, a couple of minor issues with the enblend autotools setup, fixing these would make things easier for packagers: The mercurial repository contains generated files (enblend.1, enblend.info etc...), these get rebuilt locally, resulting in a conflict that needs to be resolved every time we pull from the sourceforge repository. Ideally the repository wouldn't contain these files, though it makes sense for the dist target to build the info and man pages and include them in the tarball. The dist target does a full build of the executables even though they are not included in the tarball, this means creating a tarball for packaging as rpm/deb takes twice as long as it needs to. The dist target creates a tarball with the mercurial revision in the filename, e.g. enblend-enfuse-4.1-1bcd3b5cb866.tar.gz, this is a bit unusual but ok for development snapshots. The problem is it also includes a directory called 'enblend-enfuse-4.1-1bcd3b5cb866' even when the tarball is renamed for a stable release. So when we are packaging enblend it is necessary to change the rules every time to account for this variable directory name. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1052231/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~hugin-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
