Bug 509813 - Package sanity issues
Package sanity issues
Status: CLOSED DUPLICATE of bug 501772
Product: Fedora
Classification: Fedora
Component: atlas (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Deji Akingunola
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-06 07:59 EDT by Susi Lehtola
Modified: 2009-07-07 08:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-07 08:05:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Susi Lehtola 2009-07-06 07:59:52 EDT
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 08:39:48 EDT
(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 08:48:56 EDT
(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 09:21:33 EDT
(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 09:41:58 EDT
(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 09:44:06 EDT
In my experience, adding -g doesn't impact runtime.
Comment 6 Deji Akingunola 2009-07-06 10:01:41 EDT
(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 08:05:00 EDT
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.