Mailinglist Archive: opensuse-packaging (102 mails)

< Previous Next >
Re: [opensuse-packaging] Proposal: Update rpm configuration to fix issues and rationalize configuration
On Tue, Apr 25, 2017 at 8:38 AM, Rüdiger Meier <sweet_f_a@xxxxxx> wrote:


On 04/25/2017 02:27 PM, Ludwig Nussel wrote:

Michael Matz schrieb:

On Mon, 24 Apr 2017, Neal Gompa wrote:

* Backport the --changes option from RPM git master to rpm 4.13. This
* Change the default binary package payload compression algorithm from
old-lzma to xz. Apparently, this change was supposed to have already
* Define %_sharedstatedir as /var/lib instead of /usr/com. The current


I think all of these are no brainers.

* Revert %_libexecdir to /usr/libexec.


I'd personally like this to happen, yeah. It's in line with the original
intent of libexec and lib, and that the FHS didn't recognize it was a
long
standing bug (IMHO, it certainly was a long-standing annoyance :) ).


What's wrong with /usr/lib/name/? IMO /usr/libexec is redundant.


Isn't $PREFIX/libexec the autoconf default? I've never understood why we
don't use $LIBEXEC as expected.

It is the default for Autotools, CMake, Meson, and many other build
systems that support Unix FHS.

I've never understood why the FHS people intentionally ignored the
existing usage of /usr/libexec until 2015, but it certainly didn't
stop everyone from continuing to use it or set it as default.

Only Autotools still does /usr/com by default for @sharedstatedir@,
but that's because it supports old Unices. As far as I'm aware,
/usr/com dropped out of usage around the time Linux got started,
probably because /usr was fully repurposed for read-only data (as
opposed to storing user content) by that point and /usr/com was a
writable location. Most things moved to using /var/lib because /var
*must* be writable and the /var/lib path implies shared variable,
persistent content.

--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >