Sent from my iPhone > On Apr 28, 2015, at 00:42, Michael Schwendt <mschwendt@xxxxxxxxx> wrote: > >> On Mon, 27 Apr 2015 19:18:15 +0300, Daniel Letai wrote: >> >> Hi, >> >> 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 <lib>-devel >> package, > > 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 files? > There is only one real solution: Put .so files into the (sub-)packages > 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 > packaging@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/packaging -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
