Re: RFS: qrupdate
On Wed, Feb 4, 2009 at 12:41 PM, Jordi Gutiérrez Hermoso
<jordigh@gmail.com> wrote:
>> I think you missed my debhelper 7 comment?
>
> I'm actually using version 7, since dh_prep needs it.
Ok.
>> There are no header files in the -dev package, does fortran not need
>> external headers to be able to link to the library ?
>
> No, Fortran doesn't use headers.
oooook
>> You don't handle DEB_BUILD_OPTIONS noopt or parallel=n, please check
>> the debian-policy for info on that.
>
> I'm going to ignore both of those since this package is so tiny and
> Fortran builds so quickly.
noopt is useful for when people need to do debugging of the library or
apps using it.
>> I assume you've read libpkg-guide?
>
> Yes, is there a part of it I obviously need to read again more carefully?
Nope, just making sure you're familiar with it.
This is a fortran library though, so some things are a bit different.
>> Is the static library needed? Debian tends towards not installing them
>> where possible.
>
> It's going into the -dev package per section 4.2 of libpkg-guide and
> also following the example of lapack and blas which do the same.
Ok
>> I would assume libqrupdate1 would mainly be installed automatically
>> and the -dev package would be installed manually by people wanting to
>> use the library. If that is the case, the function-reference and
>> README should be in the -dev package. In addition the package
>> descriptions should reflect this; the lib one should be minimalist and
>> the -dev package should be aimed at folks developing software using
>> the lib.
>
> Yeah, again, Fortran is a little weird about this. I'll leave the
> shared lib in the libqrupdate1 package and the static library in the
> -dev package per the recommendations of libpkg-guide and the examples
> of lapack and blas.
Fair enough, fortran is weird.
>> You're missing ${misc:Depends} from the Depends, you should always
>> include it in case some debhelper script adds stuff to it in the
>> future.
>
> Okay, this gives me a warning, but I understand this is harmless.
The warning will go away with debhelper 7.1 (#498666).
>> You don't specify which version of the GPL your packaging is released
>> under, was that intentional?
>
> Yeah, I don't really care. Use any version of the GPL. Anyways,
> doesn't it have to be version 3 since I'm adding to the build system
> of a GPLv3 package?
Yeah, version GPLv3 is incompatible with GPLv2 IIRC, so the binaries
are GPLv3 or later no matter what. You might want to clarify that the
packaging is under any version of the GPL (or just change it to GPLv3
or later).
> - dget http://mentors.debian.net/debian/pool/main/q/qrupdate/qrupdate_1.0-1.dsc
I think you should depend on libblas-dev in case the ABI of libblas3gf
changes. Although, this is fortran, so I'm not entirely sure about
that. In any case I think it should be consistent between libblas &
liblapack.
You can drop the perl build-dep version restriction since etch will
soon be oldstable and Debian doesn't support things older than
oldstable.
> I've also set up an svn repo for this package with the pkg-scicomp team:
>
> http://svn.debian.org/viewsvn/pkg-scicomp/qrupdate/
You should add Vcs-* fields to debian/control.
Only the copyright file is a blocker though.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: