[Pkg-octave-devel] Octave 3.4
Sébastien Villemot
sebastien.villemot at ens.fr
Tue Dec 6 15:11:51 UTC 2011
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>
More information about the Pkg-octave-devel
mailing list