Re: Shared libraries unversioned .so symlinks packaging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux