Sent from my iPhone
On Apr 28, 2015, at 00:42, Michael Schwendt
> On Mon, 27 Apr 2015 19:18:15 +0300, Daniel Letai wrote:
> When building gcc 5.1 rpm (based on f22 spec) to a different prefix I
> get a list of .so unpackaged files:
How did you modify the gcc.spec to relocate the files?
I can paste the spec but
basically hard-coded _prefix and friends, and corrected errors as they popped up.
Where are those files installed without your modification?
You can use rpmls or repoquery to find out.
They're not installed.
Well, that's not entirely true. The files are installed both in origin and my fork in
the prefix/lib/gcc/... path, but a duplicate also exists in the prefix/%_lib/ path which
never gets packaged. I'm asking about this duplicate
Perhaps your %files sections don't match the changed location?
It did at first. I modified it to include more installed but not packaged files
> I know the usual solution is to place such symlinks in the
There is _no_ such "solution". The guidelines have been updated a few
times, because some packagers have put all .so files into -devel packages
without a second thought.
That makes sense. Can you provide a link to the best practice of handling .so
There is only one real solution: Put .so files into the
they belong into.
Ok, that's what I did.
Where they belong into depends on *when* they are
needed? At run-time? At build-time? Both?
They are unversioned. Not sure when they
are ever used in preference of the versioned ones.
> but for most of those libs there is no devel counterpart,
GCC is a development tool in a development package that doesn't have
-devel in its name. With a bit of fantasy one could make it depend on lots
of -devel packages just to be explicit for some of the libs, but some of
the build-time libs may be needed always, so they are not in separate
packages (except for runtime libs).
Yet the gcc src rpm does produce a few devel
packages (e.g libgccjit, libitm...)
> so I'm wondering what are best practices in this case.
Put them where they belong.
> I figure I can
> 1. Just ignore them (I have %global _unpackaged_files_terminate_build 0)
> 2. Remove them in %install
That sounds much as if you don't know what you're doing.
Or possibly the
gcc package maintainer doesn't?
I'm not a developer. OTOH I know that gcc rpm does some things that seem wrong to hard
core developers (like ignore all the include-fixed headers except limits and syslimits).
I was just trying to be thorough and cover all possibilities.
> 3. Add them to their respective %files lib
> 4. Create an %files lib-devel for each one
> Which is preferred, if at all?
> As a potential follow-up: If 1 or 3, why bother creating them in the
> first place?
packaging mailing list