Thomas Weber <thomas.weber.mail@gmail.com> (18/07/2007): > Generally, you are right. In this specific case, it's unimportant. > Octave2.1 is going to die pretty soon (as soon as we have switched all > dependending packages to 2.9). OK. > Sorry for your time, I thought you'd know that[1] NP. The FTBFS has to be fixed in the meanwhile, so... I forgot to test #417494 BTW. > So, as a warning: don't spend time with octave2.9-forge. We hope to > get rid of it soon (and even if not, due to upstream changes, it will > be split into several packages). Thanks, I already noticed this one, through #423993. But I don't see the point in not fixing the easy FTBFS, which should be quite easy (if one doesn't consider my question at the bottom of this mail). Instead, I'd be inclined to fixing the bug, and opening a dummy bug to ensure the package doesn't migrate to testing. > That's okay, the Octave interpreter knows where to find its own > libraries. Fine. > [1] Then again, who knows how long other packages in Debian will want > to continue using 2.1. Just to get the idea: | # wget+gunzip | $ grep-dctrl -F Build-Depends "octave2.1-headers" -s Package < ../../Sources | Package: h5utils [y] | Package: octave2.1-forge [x] [y] | Package: octaviz [x] [y] | Package: plplot | Package: semidef-oct [x] [y] | Package: shogun | Package: xmds x: POD-maintained y: FTBFS due to gfortranA So we would have 4 (outside-maintained) packages to switch from 2.1 to 2.9, right? Are the POD-maintained packages ready for a 2.1 to 2.9 switch? Back to my FTBFS fixes, I don't really understand how things are done to generate the appropriate (Build-)Depends, since in a svn working copy: | $ grep -r gfortran . \ | | grep -v /.svn/ \ | | grep -v /tags/ \ | | grep -v changelog: \ | | awk -F: '{print $1}' | ./octave-forge/branches/2.9transition/debian/control | ./octave2.1-forge/trunk/debian/control | ./octave2.9-forge/trunk/debian/control | ./octave2.9/branches/etch/debian/in/control | ./octave2.9/branches/etch/debian/in/control | ./octave2.9/branches/etch/debian/rules My first guess would be that the headers are (or should be) holding the Depends, and are used by the other packages in Build-Depends, but I don't understand which tags/trunk I should be using to fix this. Any pointer, please? Cheers, -- Cyril Brulebois
Attachment:
pgp8774eYO_AE.pgp
Description: PGP signature