Summary/Minutes for today's FESCo meeting (2012-12-19)

Toshio Kuratomi a.badger at gmail.com
Fri Dec 21 08:42:14 UTC 2012


On Fri, Dec 21, 2012 at 07:45:45AM +0000, Matthew Garrett wrote:
> On Thu, Dec 20, 2012 at 11:24:09PM -0800, Toshio Kuratomi wrote:
> 
> > 2) the systemd exceptions allows placing files in %{_prefix}/lib rather
> > than %{_libdir} (the exceptions allow both putting the helper apps in there
> > which would generally be okay with just a multilib exception and the unit
> > files which are arch specific data and therefore usually go in %{_libdir}
> > and therefore needed a special exception).  The only reason people can drag
> > %{_libexecdir} in to this discussion is that helper binaries are allowed in
> > either %{_libdir} or %{_libexecdir}.  In the context of forcing people to
> > use a specific directory not specified by standards its meaningless because
> > %{_libdir} is a suitable alternative.
> 
> I think the libexec discussion is fairly relevant. Right now a package 
> can drop binaries in libexecdir and have a consistent path regardless of 
> the architecture, which is valuable. However, doing so results in 
> inconsistencies with other distributions which don't provide libexecdir. 
> This is clearly suboptimal, and it's reasonable to ask that the 
> packaging guidelines recognise that and handle it without requiring 
> additional exceptions - if a package wouldn't require an exception to 
> install binaries in libexec, it shouldn't need an exception install 
> binaries in lib.
> 
I think the FPC has gotten pretty close to that.  I reopened discussion in
the FPC ticket about this because we recently approved packages which were
exmpt from multilib from having to choose %{_libdir} over %{_prefix}/lib.for
things like helper binaries (the guideline was brought up because of java
but we passed a generic guideline update that can include helper binaries as
well).  However, people were concerned that packagers wouldn't necessarily judge
correctly whether their packages were truly deserving to be exempt from
multilib so the packages needed to be confirmed to be exempt from multilib
requirements first.  I've been calling that a "multilib exception" but
perhaps "multilib exemption" would be clearer.  It's not about this being an
exceptional or special case.  It's a case where if you fit certain criteria
then you are exempt from certain restrictions.  I have been unable to think
of any reason that the types of binaries that belong in libexec would fail
to be exempted from the considerations of multilib so I think we're in
agreement about what the expected outcome should be for those types of
files.

However, you also miss my point.  Adam's message was saying that the
guidelines forced people to use libexecdir and then went on to point out the
drawbacks of forcing specifically libexecdir on upstreams that didn't have that
coded in.  So, as I said, in that context it's meaningless to bring up
arguments that are only addressed to libexecdir because %{_libdir} is an
alternative.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20121221/3031eb90/attachment.sig>


More information about the devel mailing list