Bug 509813 - Package sanity issues
Summary: Package sanity issues
Keywords:
Status: CLOSED DUPLICATE of bug 501772
Alias: None
Product: Fedora
Classification: Fedora
Component: atlas
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Deji Akingunola
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-06 11:59 UTC by Susi Lehtola
Modified: 2009-07-07 12:05 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-07 12:05:00 UTC
Type: ---


Attachments (Terms of Use)

Description Susi Lehtola 2009-07-06 11:59:52 UTC
A couple of sanity issues:

- Debuginfo packages are broken, output from gdb:
warning: "/usr/lib/debug/usr/lib64/atlas/liblapack.so.3.0.debug": The separate debug info file has no debug info
[Thread debugging using libthread_db enabled]
warning: "/usr/lib/debug/usr/lib64/atlas/libf77blas.so.3.0.debug": The separate debug info file has no debug info
warning: "/usr/lib/debug/usr/lib64/atlas/libcblas.so.3.0.debug": The separate debug info file has no debug info
warning: "/usr/lib/debug/usr/lib64/atlas/libatlas.so.3.0.debug": The separate debug info file has no debug info

The files are just 21B in size, so they're empty.

- Optimization flags are not used (which is probably the reason to the above.)

- -devel packages do not provide -static, even if they contain static libraries.

- Time stamps are not preserved, use cp -p instead of cp.

Comment 1 Deji Akingunola 2009-07-06 12:39:48 UTC
(In reply to comment #0)
> A couple of sanity issues:
> 
> - Debuginfo packages are broken, output from gdb:
> warning: "/usr/lib/debug/usr/lib64/atlas/liblapack.so.3.0.debug": The separate
> debug info file has no debug info
> [Thread debugging using libthread_db enabled]
> warning: "/usr/lib/debug/usr/lib64/atlas/libf77blas.so.3.0.debug": The separate
> debug info file has no debug info
> warning: "/usr/lib/debug/usr/lib64/atlas/libcblas.so.3.0.debug": The separate
> debug info file has no debug info
> warning: "/usr/lib/debug/usr/lib64/atlas/libatlas.so.3.0.debug": The separate
> debug info file has no debug info
> 
> The files are just 21B in size, so they're empty.
> 
> - Optimization flags are not used (which is probably the reason to the above.)
> 
Atlas is by design built with carefully selected compiler flags for optimal performance. I've been hesitant in adding the '-g' flag in the past until I can assure myself (or can be properly assured) that it is not going to negatively affect the libraries performance.
  
> - -devel packages do not provide -static, even if they contain static
> libraries.
>
The static libs are packaged in the -devel subpackage because the shared libs depend on them, IIRC.
 
> - Time stamps are not preserved, use cp -p instead of cp.  
How so, have you look at the spec file. I'm usually careful to use the '-p' option with cp.

Comment 2 Susi Lehtola 2009-07-06 12:48:56 UTC
(In reply to comment #1)
> > - Optimization flags are not used (which is probably the reason to the above.)
> > 
> Atlas is by design built with carefully selected compiler flags for optimal
> performance. I've been hesitant in adding the '-g' flag in the past until I can
> assure myself (or can be properly assured) that it is not going to negatively
> affect the libraries performance.

Does this package have a special permission from FesCo allowing not to use them?
 
> > - -devel packages do not provide -static, even if they contain static
> > libraries.
> >
> The static libs are packaged in the -devel subpackage because the shared libs
> depend on them, IIRC.

That sounds like a logical impossibility. If the shared, dynamic libraries have been linked against the static libraries, they themselves contain the code of the static library. That's the whole idea of static linking.

And this was not the question, you just have to put a 

Provides: atlas-static = %{version}-%{release}
to the -devel package (and for the sse -devel package Provides: atlas-sse-static = %{version}-%{release} and so on).

> > - Time stamps are not preserved, use cp -p instead of cp.  
> How so, have you look at the spec file. I'm usually careful to use the '-p'
> option with cp.  

Yes, I have. In %setup:

cp %{SOURCE1} doc

Comment 3 Deji Akingunola 2009-07-06 13:21:33 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > > - Optimization flags are not used (which is probably the reason to the above.)
> > > 
> > Atlas is by design built with carefully selected compiler flags for optimal
> > performance. I've been hesitant in adding the '-g' flag in the past until I can
> > assure myself (or can be properly assured) that it is not going to negatively
> > affect the libraries performance.
> 
> Does this package have a special permission from FesCo allowing not to use
> them?
>
Special permission? If you feel strongly about it, you can raise it with them.
 
> > > - -devel packages do not provide -static, even if they contain static
> > > libraries.
> > >
> > The static libs are packaged in the -devel subpackage because the shared libs
> > depend on them, IIRC.
> 
> That sounds like a logical impossibility. If the shared, dynamic libraries have
> been linked against the static libraries, they themselves contain the code of
> the static library. That's the whole idea of static linking.
> 
> And this was not the question, you just have to put a 
> 
> Provides: atlas-static = %{version}-%{release}
> to the -devel package (and for the sse -devel package Provides:
> atlas-sse-static = %{version}-%{release} and so on).
> 
What will be the use of such Provides? I think I will just create a -static subpackage and put the *.a libs there.

> > > - Time stamps are not preserved, use cp -p instead of cp.  
> > How so, have you look at the spec file. I'm usually careful to use the '-p'
> > option with cp.  
> 
> Yes, I have. In %setup:
> 
> cp %{SOURCE1} doc  
Will fix.

Comment 4 Susi Lehtola 2009-07-06 13:41:58 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > > - Optimization flags are not used (which is probably the reason to the above.)
> > > > 
> > > Atlas is by design built with carefully selected compiler flags for optimal
> > > performance. I've been hesitant in adding the '-g' flag in the past until I can
> > > assure myself (or can be properly assured) that it is not going to negatively
> > > affect the libraries performance.

How does the tuning of atlas work? Does it change the optimization flags by itself..?

Have you performed any benchmarks to see what the effect of using the Fedora build flags would be? You could still customize them by e.g. adding -fomit-frame-pointer -mfpmath=sse -msse to the SSE version(s).

> > Does this package have a special permission from FesCo allowing not to use
> > them?
> >
> Special permission? If you feel strongly about it, you can raise it with them.

I think that's the policy. Sent a mail to packaging list.

> > > > - -devel packages do not provide -static, even if they contain static
> > > > libraries.
> > > >
> > > The static libs are packaged in the -devel subpackage because the shared libs
> > > depend on them, IIRC.
> > 
> > That sounds like a logical impossibility. If the shared, dynamic libraries have
> > been linked against the static libraries, they themselves contain the code of
> > the static library. That's the whole idea of static linking.
> > 
> > And this was not the question, you just have to put a 
> > 
> > Provides: atlas-static = %{version}-%{release}
> > to the -devel package (and for the sse -devel package Provides:
> > atlas-sse-static = %{version}-%{release} and so on).
> > 
> What will be the use of such Provides? I think I will just create a -static
> subpackage and put the *.a libs there.

OK, that's a valid option too.

Comment 5 Rex Dieter 2009-07-06 13:44:06 UTC
In my experience, adding -g doesn't impact runtime.

Comment 6 Deji Akingunola 2009-07-06 14:01:41 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > > - Optimization flags are not used (which is probably the reason to the above.)
> > > > > 
> > > > Atlas is by design built with carefully selected compiler flags for optimal
> > > > performance. I've been hesitant in adding the '-g' flag in the past until I can
> > > > assure myself (or can be properly assured) that it is not going to negatively
> > > > affect the libraries performance.
> 
> How does the tuning of atlas work? Does it change the optimization flags by
> itself..?
> 

http://math-atlas.sourceforge.net/atlas_install/atlas_install.html#SECTION00042000000000000000

Comment 7 Rex Dieter 2009-07-07 12:05:00 UTC
this is essentially, a dup of existing bug #501772

*** This bug has been marked as a duplicate of bug 501772 ***


Note You need to log in before you can comment on or make changes to this bug.