[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status of gfortran transition



Greetings!

Kumar Appaiah <akumar@ee.iitm.ac.in> writes:

> On Thu, Oct 25, 2007 at 11:05:19AM -0400, Camm Maguire wrote:
> > Greetings!
> 
> First of all, it's great to have you back, Camm!
> 
> > Just uploaded refblas3_1.2-9 to experimental.  Hope to get lapack and
> > atlas in in the next few days.
> 
> I just had a look at it. While it seems OK, I definitely have to crib
> about the diff.gz. If you observe, it has many lines of the following
> form:
> 
> --- refblas3-1.2.orig/src/cgbmv.f
> +++ refblas3-1.2/src/cgbmv.f
> @@ -142,7 +142,7 @@
>        LOGICAL            LSAME
>        EXTERNAL           LSAME
>  *     .. External Subroutines ..
> -      EXTERNAL           XERBLA
> +      EXTERNAL           XERBLI
>  *     .. Intrinsic Functions ..
>        INTRINSIC          CONJG, MAX, MIN
>  *     ..
> @@ -171,7 +171,7 @@
>           INFO = 13
>        END IF
>        IF( INFO.NE.0 )THEN
> -         CALL XERBLA( 'CGBMV ', INFO )
> +         CALL XERBLI( 'CGBMV ', INFO )
>           RETURN
>        END IF
>  *
> (And many more).
> 
> I would really request you to move to a patching system like quilt or
> dpatch in order to isolate the differences to diff files, as that
> makes things very easy to handle, isolating the upstream from the
> Debian packaging.
> 

Thanks for the suggestion!  I heartily agree -- I am just so old that
I've wound up implementing an analogous facility in terms of makefile
rules (aka lapack debian/rules, not here of course), and always resist
learning anything new :-), especially that might be replaced in short
order.  What is th 10 year solution?

Take care,

> > I distinctly remember being required to come up with the naming scheme
> > (refblas3 provides libblas.so.3 (virtual)) to get around difficulties
> > with ldconfig and earlier incarnations of the packaging system (in
> > conflict/replace with the earlier libblas)  though I cannot recall the
> > precise details at this point.  It would make sense to call the
> > package libblas3/libblas3-dev and have these also name virtual
> > packages which atlas could provide.  Will this work?  Anyone have a
> > better idea?  Now would appear a good time to put in what we'll want
> > to have for the next few years.
> 
> This is best addressed by Riku or doko. I'll stay out of this! :-)
> 
> > Finally, it appears as though we might no longer need to mess with
> > /etc/ld.so.conf to get the preferential loading -- that automatically
> > certain subdirs of /usr/lib are searched by ld.so first.   Any
> > succinct update on the latest here would be most appreciated.
> 
> Same here.
> 
> > What is the plan from experimental to unstable?
> 
> Well, I volunteer to compile rdepends one by one, if I can, and for
> the rest, ping the maintainer to do so. I think that would check all
> the issues with the refblas and lapack packages, and should bring us
> to good shape with respect to moving it to unstable. However, I am a
> trifle worried about the architectures, since that's where you may
> face most of the problems.
> 
> Anyway, I think I'll now take the back seat, and wait for you to take
> over. But do consider my request to use quilt or dpatch.
> 
> Thanks.
> 
> Kumar
> -- 
> Kumar Appaiah,
> 458, Jamuna Hostel,
> Indian Institute of Technology Madras,
> Chennai - 600 036
> 
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



Reply to: