hugin-devs team mailing list archive

[Bruno Postle <1052231@xxxxxxxxxxxxxxxxxx>]

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