[Pkg-octave-devel] Octave 3.4

[Sébastien Villemot]

Thomas Weber <tweber at debian.org> writes:

> the current packaging can be found at 
> http://anonscm.debian.org/gitweb/?p=users/tweber/octave.git;a=summary
> It is based on the octave.git repository we have on git.debian.org.
> Unless anybody sees some real problem with the repo, I intend to push to
> our normal repository soon. Uploads will go to experimental.

Thanks for your work. I have been able to build the package, and I
successfully tested it against a simple Dynare example.

I have a few small issues:

- dh_autoreconf_clean is not run by the clean rule. As a consequence,
  modified autotools-generated files are left in the build tree. A patch
  is attached. If this is intentional, it would be useful to add a
  clarification comment in debian/rules.

- I cannot run git-buildpackage without the --git-ignore-new option,
  because some files tracked by git are deleted by debian/clean. A
  similar issue is discussed in this old thread:

   http://www.mail-archive.com/debian-ocaml-maint@lists.debian.org/msg22803.html

  ...and the conclusion is that a patch would be more appropriate for
  removing generated files from upstream tarball. An alternative
  solution would be to use "git update-index --assume-unchanged", but
  this is local to a working copy and does not propagate to remote
  repositories if my understanding is correct.

- The current changelog entry does not list all the bugs closed in git
  log messages, but I guess this is only because git-dch has not yet
  been run

> There are quite some TODOs, but for an experimental upload, none of them
> are showblockers:

[...]

>  - Add the conflicts necessary to replace octave3.2 

The only real conflicts seem to concern the alternatives set up by
octave3.2, octave3.2-headers and octave3.2-info. Since the conflict is
going to be permanent, we have to use Conflicts and not Breaks (policy
7.4). A patch is attached.

The solution would be different if we planned to provide a dummy
transitional octave3.2 only depending on octave 3.4, but I don't think
this is what we want for two reasons:

- the new octave package does not provide octave 3.2 (it provides a
  different version), so the dependency would be misleading to the user

- this would immediately break all octave-forge packages that have not
  been yet recompiled with octave 3.4.

That's all for the moment, I’ll have a look at the other TODOs later.

Best,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Run-dh_autoreconf_clean-in-clean-rule.patch
Type: text/x-diff
Size: 722 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20111206/70dea5e1/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-Conflicts-with-octave3.2-packages.patch
Type: text/x-diff
Size: 1611 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20111206/70dea5e1/attachment-0001.patch>
-------------- next part --------------


-- 
Sébastien Villemot
Researcher in Economics & Debian Maintainer
http://www.dynare.org/sebastien
Phone: +33-1-40-77-49-90 - GPG Key: 4096R/381A7594
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20111206/70dea5e1/attachment.pgp>