[Bug 476398] Review Request: eclib - A Library for Doing Computations on Elliptic Curves

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=476398





--- Comment #20 from Conrad Meyer <konrad at tylerc.org>  2009-03-19 13:40:26 EDT ---
(In reply to comment #19)
> Find out where the -I/usr/local/include and -L/usr/local/lib come from, then
> get rid of them for sake of reproducible builds. No issue for builds in clean
> buildroots. Not clean for ordinary builds on installed Fedora systems where
> /usr/local might contain locally built stuff.

This doesn't matter on Koji or in mock.

> > %package        devel
> 
> According to the guidelines, this ought to
> Requires: %{name} = %{version}-%{release}
> to enforce a matching pair of development files and binaries.
> This guideline alone should make a packager realise "oh, wait, there are shared
> libs in this package, so not creating a main library package for them would be
> strange".

Except you don't require the main package if one doesn't exist. It's not
obvious.

> In reply to comment 3:
> > - fix the soname mess, probably install to a subdirectory of _libdir?
> 
> > %{_libdir}/%{name}/*.so
> > %{_libdir}/%{name}/lib*.a
> 
> That doesn't fix the "soname mess".

That's a comma. It's there to separate two ideas.

> It makes things worse, because you've moved the shared libs out of run-timer
> linker's search path. Any application linked to these libs would fail to start.

Right, and the exactly one application that cares isn't in Fedora yet and ships
its own copy of eclib.

> The static archive would not be found either at build-time. It would be
> necessary to adjust the compiler's library search path (-L%{_libdir}/%{name}),
> which probably no existing application does, because it expects to find the
> eclib libraries in default search path.

Doesn't matter, it's easy enough to adjust search path at build time for static
libs.

> Further, the shared libraries [if moved incorrectly as in current spec file]
> are still seen by rpmbuild's dependency generators. They still lead to
> automatic SONAME "Provides" and "Requires", even if the libraries won't be
> found at run-time.

They can be moved back if you like.

> Noticing that the package builds several test programs, consider including a
> %check section for "make check". It is good packaging-practise to run a
> test-suite at build-time unless it is known/confirmed to be broken.

I'm happy to take a patch.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.