[Bug 1653] MPFR spec URL wrong

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1653

--- Comment #2 from Chris Johns <chrisj at rtems.org> 2010-08-04 23:45:54 CDT ---
(In reply to comment #1)
> (In reply to comment #0)
> > MPFR has a new release
> Are you referring to 3.0.0? 

Yes.

> For now, I am not intending to upgrade to it, but

Sure, and I was not asking for you to upgrade it. :)

> prefer to stay with mpfr-2.*, for 2 reasons:
> 
> a) mpfr-3.0.0 is known to have GCC-integration issues.
> b) None of the currently supported distros ships mpfr-3.0.0
> nor does any of the supported GCC versions require 3.0.0.
> 
> > and the spec file URL is wrong. It is now:
> > 
> > http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2.tar.bz2
> OK, will update the URL.

Thanks.

> 
> > The naming in this project makes keeping this link up to date a problem.
> Provided the naming scheme of their URL, this will not be possible ;)
> 
> Replacing the tarball would be serious mistake, so they'd have to increment the
> version (http://www.mpfr.org/mpfr-<version>/mpfr-<version>.tar.bz2).
> 

They should link the file from the current page to the final location and then
it does not matter what we use nor what happens in their release cycle.

> 
> > <side-issue>
> > 
> > I have also noticed:
> > 
> >  http://www.rtems.org/ftp/pub/rtems/SOURCES/4.11
> > 
> > does not contain some of these sources:
> > 
> >  http://www.multiprecision.org/mpc/download/mpc-0.8.1.tar.gz
> >  http://www.mpfr.org/mpfr-current/mpfr-2.4.2.tar.bz2
> >  ftp://ftp.gnu.org/gnu/gmp/gmp-4.3.2.tar.bz2
> >  ftp://sources.redhat.com/pub/newlib/newlib-1.18.0.tar.gz
> >  ftp://ftp.gnu.org/gnu/gcc/gcc-4.5.1/gcc-core-4.5.1.tar.bz2
> >  ftp://ftp.gnu.org/gnu/gcc/gcc-4.5.1/gcc-g++-4.5.1.tar.bz2
> > 
> > plus patches. I am willing to automate the updating of these files based on the
> > references in the spec files and to remove files after 6 months (or how-ever
> > long) if not referenced in spec files. Please let me know if it is ok for me to
> > do this.
> > 
> > </side-issues>
> Not OK with me.
> 
> I am populating this directory from the contents of the rpms. Currently this is
> done manually after a built-spin has completed, which usually takes 2 days and
> thus occasionally causes me to forget about it.

Ah yes this is more correct but do you think they would not be the same. We
should provide MD5 checksums on these files.

> 
> I.e. the appropriate step would be to extend the scripts I am using to maintain
> the rpm repositories to automatically populate/cleanup these directories. So
> far this hasn't happened.

I am more than happy for you to handle this. If this directory does not have
the source I go to the location in the spec file.

The spec files reference some source packages that as far as I can see you do
not use such as mpfr etc, and I assume this is due to the host having a
suitable package installed so no need for the source. Is this the case ?

Please note, I have added one or more of the other sources before you raised
you  objection. I can remove if you wish.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.