Saul Wold <s...@linux.intel.com> writes:
>>>> Things *are* expected to move around. E.g. /usr/lib/openssh/sftp-server
>>>> becomes /usr/lib/sftp-server now.
>>>
>>> Right, so don't use Debian as a rationale for this approach.
>>
>> Debian defines libexecdir to be /usr/lib (+multiarch). It might set
>> sometimes per-package '--libexecdir=${libexecdir}/<package>' configure
>> options, but libexecdir is always /usr/lib there.
>
> As I read though this, a couple things I noted from some of the
> available information, the GNU Directory section you quoted earlier
> actually suggests a package-name directory should be included.
Yes; automake calls this
pkglibexecdir = $(libexecdir)/@PACKAGE@
and lot of packages are using it already to install their files.
> The definition of ‘libexecdir’ is the same for all packages, so you
> should install your data in a subdirectory thereof. Most packages
> install their data under $(libexecdir)/package-name/, possibly within
> additional subdirectories thereof, such as $(libexecdir)/package-
> name/machine/version.
>
> And as you pointed out below, the FHS also touches on having a
> sub-directory for applications to use for non-user object and
> internal binaries (like plugins).
Yes; but this is thing of the package, not of the distribution. When a
distribution thinks, a package pollutes $(libexecdir), the distribution
can fix *this* package. But $(libexecdir) provided by the distribution
must never contain the package name.
>> When we really do not want executables under ${libdir}, we can set
>>
>> libexecdir = ${prefix}/lib/libexec
>>
>> (which might be a good setting for world-builds to detect some kind of
>> libexecdir related problems).
>>
> I prefer what Ross suggested, fixing libexecdir to be
> ${exec_prefix}/lib/${BPN}
$(libexecdir) has the same meaning like $(bindir); so why do we not have
bindir = $(prefix)/bin/${BPN}
?
Again: $(libexecdir) must be the same for every package. All major
linux distributions follow this; why should oe differ from this rule?
>>> If we want to be like the half of the world that does the same as
>>> Fedora then we can revert back to /usr/libexec. Or we can be like
>>> the half of the world that does the same as Debian and use something
>>> similar to ${prefix}/lib/$(DEB_SOURCE_PACKAGE) (as used in CDBS and
>>> Debhelper):
>>
>> Debian does *not* include the package name since mid 2011
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541458
>>
> I just looked at a Debian build and /usr/lib is abound with package
> directories.
Nobody forbids this and it is completely fine and suggested that
packages install their files below $(pkglibexecdir). But Debian
defines libexecdir as /usr/lib (plus an optional multiarch tag from
DEB_HOST_MULTIARCH (whatever this is)).
> Since I did the last libexecdir change, I will start to investigate
> changing libexecdir to be ${exec_prefix}/lib/${BPN}.
This is a no-go because it breaks the GNU standard like the recent
value. fwiw, my preferences for libexecdir are (in this order):
1. ${prefix}/libexec
--> clean separation, commonly used, but not FHS compliant (unless
somebody interprets "/usr/lib<qual> : Alternate format libraries
(optional)" with '<qual>=exec')
2. ${prefix}/lib
--> follows the Debian way and is 100% FHS compliant, but might
pollute ${libdir} and might introduce regressions in oe packaging
3. ${prefix}/lib/libexec
--> clean separation, probably FHS compliant, but smells hacky
> The concern I have with this will be plugins and other executable
> binaries created in a multilib environment.
Plugins (aka "libraries to be loaded") are not interesting (they do not
belong into ${libexecdir}). Executables within ${libexecdir} are to be
handled like these in ${bindir}, so that a proper libexecdir won't cause
any new multilib issue.
Enrico
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
