Hi, Thank you for your detailed answer to this problem.
On Tue, Jul 2, 2013 at 7:24 PM, Matthias Klose <d...@debian.org> wrote: > Control: severity -1 important > Control: tag -1 + help > > On 07/02/13 11:12, Ryo IGARASHI wrote: >> Package: gfortran Version: 4:4.8.1-2 Severity: critical Justification: >> breaks unrelated software >> >> Dear Maintainer, >> >> Currently, gfortran 4.7 to 4.8 transition causes many failures when >> compiling user code. > > Downgrading. This affects "only" some packages using Fortran90 files, and as > it looks it was handled in the past outside the gfortran package. > > As you write, these affects Fortran90 code, nothing broken with libraries > which don't use Fortran90 features. I am not against this severity change. What I observed was the update of the "gfortran" package causes some lib*-dev package break. > Looks this is known upstream, see http://gcc.gnu.org/PR49138 for the GCC > issue, and https://bugs.linuxfoundation.org/show_bug.cgi?id=757 for the > general issue. Thank you for the pointer. I didn't know about the upstream info. >> This is hidden dependency, > > ... for Fortran90 code only. So something is needed to record the Fortran mod > version for those packages. > > $ echo "module m; end module m" > test.f90 > $ gfortran test.f90; zcat -f m.mod | head -n 1 > GFORTRAN module version '10' created from test.f90 > > Use zcat to be prepared for compressed mod files in 4.9. > > So as a first step, this mod version should be included in a package using > Fortran90, so that you can determine which version was used to build the > package. Thank you very much again that I can get the module version just using zcat. I can find the current gfortran-4.8 in sid creates version 10 and gfortran-4.9 creates version 10. This could remind me the following issue: You (Debian toolchain maintainers) are packaging very carefully in order to co-exist different major version of compilers. However, the lib*-dev packages which contains Fortran90 .mod files can only be functional with only one, i.e., 'default' compiler. >> However, I believe this incompatibiliy is not a user packager's fault. >> >> I believe that these issue can be more easily handled by gfortran toolchain >> layer. > > Well, there is currently no mechanism to record the gfortran module version. > This has to happen in the packages using fortran90 modules. Some > infrastructure for that could be added in the gfortran-4.x packages. I see. As long as gfortran module version is not recorded in the package info, there is currently no way to detect which package needs binNMU. I believe that what kind of scheme is needed for robust debian packaging is still debatable. > This looks like a more general issue, but specific to Fortran90. The severity > is overrated. I think if you want to properly address this, > > - then open a bug report for general, or come up with a proposal > for debian-policy, or create a fortran90 policy. > > - file rc bug reports for all packages using fortran90 to include information > which fortran module version it was built with (after coming up with > a proposal how to record that). This is needed anyway to identify > all packages which need binNMUs for future version changes. OK. I will start to think of this issue and create a general bug report for the possible solution and/or fortran90 policy. I will also raise this issue to debian-science, since most of the Fortran90 software are science related. > PS: Thanks for Tobias for helping with this issue. I would also like to say thank you to him. Best regards, -- Ryo IGARASHI, Ph.D. rigar...@gmail.com
signature.asc
Description: Digital signature
