[packages/FHS] introduce /usr/{,local/}libexec directories

Jan Rękorajski baggins at pld-linux.org
Tue Jul 11 01:56:52 CEST 2017


On Mon, 10 Jul 2017, Jakub Bogusz wrote:

> On Mon, Jul 10, 2017 at 04:57:30PM +0200, Tomasz Pala wrote:
> > On Mon, Jul 10, 2017 at 20:02:48 +0900, Jan Rękorajski wrote:
> > 
> > > If you want me to keep this commit and directory then follow up by:
> > > 
> > > a) updating rpm macros
> > 
> > Yes, I was considering this point. Just wondering, what would break (in
> > theory: nothing should) and how to perform the validation. Didn't want
> > to do such change without more feedback, so now - if you already
> > summoned this subject, I'll wait a few days for any comments.
> > 
> > I've already reviewed these and only one (re)definition needs to be
> > adjusted (in /usr/lib/rpm/macros.d/pld), remaining macros seem to be
> > cascading properly.
> 
> Note that there are some inter-package consistency requirements.
> 
> And just like some packages having hardcoded /usr/libexec, and "require
> hackery" to use libdir subdirectory, the others have hardcoded /usr/lib**
> for this purpose and would "require hackery" to use libexec.
> 
> Without using libexec consequently, I don't see any profits (single
> place for internal binaries).

I see a profit - not doing that hackery. The other hackery is for mixing
arch and noarch subpackages. Right now it's either all or nothing -
libdir or datadir (see git-core ping-pong), or hacking program to understand
both locations. With libexec dir we'll have it the way author wanted and
will be able to build noarch subpackages.

-- 
Jan Rękorajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


More information about the pld-devel-en mailing list