Proposal: Update rpm configuration to fix issues and rationalize configuration

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal: Update rpm configuration to fix issues and rationalize configuration

Neal Gompa
Hello,

With some guidance from Michael Schroeder, I'd like to propose a few
changes to RPM for Factory / Tumbleweed in time for SLE 15.

* Backport the --changes option from RPM git master to rpm 4.13. This
is a very simple change that exposes RPM's changelog data with full
timestamps. Previously, the commit to support changelogs with full
timestamps was backported for reproducible builds work, but the
commits for users to access that information easily was not. This is a
trivial change, as it merely adds a popt definition and extends the
man page to include info on the new parameter.

* Change the default binary package payload compression algorithm from
old-lzma to xz. Apparently, this change was supposed to have already
happened some time ago, but it didn't. This change is simple and
brings openSUSE in line with Red Hat Enterprise Linux/CentOS/Fedora
and Mageia, as both use xz payloads now. Packages compressed with
old-lzma will still be readable by rpm, and even packages compressed
with xz will be readable by SLES 12 / OpenSUSE Leap 42 systems.

* Define %_sharedstatedir as /var/lib instead of /usr/com. The current
path for shared state content (/usr/com) isn't recognized by FHS,
whereas /var/lib is recognized as suitable for this purpose, and is
currently used as such by Red Hat Enterprise Linux/CentOS/Fedora;
Mageia; and Debian/Ubuntu systems. This is expected to be a trivial
change, as the /usr/com path has been broken for years and isn't even
really used by anything.

* Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides
rpm to define %_libexecdir as /usr/lib, which leads to pollution of
the /usr/lib directory with executable content as well as 64-bit
content when there shouldn't be any. This path has been in use on Red
Hat Enterprise Linux/CentOS/Fedora and Mageia systems in the Linux
world, but has its origins in BSD and is still used today in BSDs and
variants (like Mac OS X). The usage of /usr/libexec for libexec
content has also finally been recognized by FHS with v3.0, released in
2015. This is a breaking change, as it means that as packages are
rebuilt, libexec content *should* migrate from /usr/lib to
/usr/libexec. The major advantage of migrating the libexec content is
that it will make openSUSE consistent with other major RPM-based Linux
distributions, and ease efforts in supporting SLE/openSUSE
Leap/openSUSE Tumbleweed alongside Red Hat/CentOS/Fedora by removing
the need for hacks and tweaks to support two different hierarchies.

With the exception of the --changes backport, all of these proposed
changes are geared towards improving compatibility across RPM-based
Linux distributions, particularly the two commercial ones: Red Hat
Enterprise Linux and SUSE Linux Enterprise. I believe that by doing
this, we can make it easier for people to be encouraged to support
SLE/openSUSE as a first class platform alongside Red Hat/CentOS/Fedora
for FOSS and commercial software.

Best regards,
Neal

--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [opensuse-factory] Proposal: Update rpm configuration to fix issues and rationalize configuration

Ruediger Meier
On 04/24/2017 04:19 PM, Neal Gompa wrote:
> Hello,
>
> With some guidance from Michael Schroeder, I'd like to propose a few
> changes to RPM for Factory / Tumbleweed in time for SLE 15.
>
> * Backport the --changes option from RPM git master to rpm 4.13.

What is the difference to the existing --changelog option?

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Jan Engelhardt-4
In reply to this post by Neal Gompa

On Monday 2017-04-24 16:19, Neal Gompa wrote:
>
>* Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides
>rpm to define %_libexecdir as /usr/lib, which leads to pollution of
>the /usr/lib directory with executable content as well as 64-bit
>content when there shouldn't be any.

Notice how systemd uses

        rootlibexecdir=$(rootprefix)/lib/systemd                                                            

Since a certain figure associated with the project is working with
RedHat, I can't help but think whether maybe SUSE was ahead of its time
to consolidate lib and libexec and that systemd copied our idea :-)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Neal Gompa
On Mon, Apr 24, 2017 at 10:27 AM, Jan Engelhardt <[hidden email]> wrote:

>
> On Monday 2017-04-24 16:19, Neal Gompa wrote:
>>
>>* Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides
>>rpm to define %_libexecdir as /usr/lib, which leads to pollution of
>>the /usr/lib directory with executable content as well as 64-bit
>>content when there shouldn't be any.
>
> Notice how systemd uses
>
>         rootlibexecdir=$(rootprefix)/lib/systemd
>
> Since a certain figure associated with the project is working with
> RedHat, I can't help but think whether maybe SUSE was ahead of its time
> to consolidate lib and libexec and that systemd copied our idea :-)

That was due to Debian wanting the systemd units in the root while not
being willing to add /share. Using /lib was the compromise. Systemd is
a very strange exception to all of this, because of Debian... :/

--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Jan Engelhardt-4
In reply to this post by Jan Engelhardt-4
On Monday 2017-04-24 16:27, Jan Engelhardt wrote:

>
>On Monday 2017-04-24 16:19, Neal Gompa wrote:
>>
>>* Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides
>>rpm to define %_libexecdir as /usr/lib, which leads to pollution of
>>the /usr/lib directory with executable content as well as 64-bit
>>content when there shouldn't be any.
>
>Notice how systemd uses
>
> rootlibexecdir=$(rootprefix)/lib/systemd                                                            
>
>Since a certain figure associated with the project is working with
>RedHat, I can't help but think whether maybe SUSE was ahead of its time
>to consolidate lib and libexec and that systemd copied our idea :-)
(Trying to imply here that systemd's use of lib over libexec is the
beginning of the end of libexec on Fedora..)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Neal Gompa
On Mon, Apr 24, 2017 at 10:29 AM, Jan Engelhardt <[hidden email]> wrote:

> On Monday 2017-04-24 16:27, Jan Engelhardt wrote:
>
>>
>>On Monday 2017-04-24 16:19, Neal Gompa wrote:
>>>
>>>* Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides
>>>rpm to define %_libexecdir as /usr/lib, which leads to pollution of
>>>the /usr/lib directory with executable content as well as 64-bit
>>>content when there shouldn't be any.
>>
>>Notice how systemd uses
>>
>>       rootlibexecdir=$(rootprefix)/lib/systemd
>>
>>Since a certain figure associated with the project is working with
>>RedHat, I can't help but think whether maybe SUSE was ahead of its time
>>to consolidate lib and libexec and that systemd copied our idea :-)
> (Trying to imply here that systemd's use of lib over libexec is the
> beginning of the end of libexec on Fedora..)

Incidentally, it was a huge mess to get that change in Fedora, as the
units were supposed to be in /usr/share/systemd instead, while the
binaries were in /usr/libexec/systemd. The change was made (under
protest) because systemd guys wanted the paths to be exactly the same
everywhere for systemd units and things. I continue to disagree with
this change and I would rather see it fixed at some point, but this is
not about the peculiarities of systemd.

--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [opensuse-factory] Proposal: Update rpm configuration to fix issues and rationalize configuration

Neal Gompa
In reply to this post by Ruediger Meier
On Mon, Apr 24, 2017 at 10:27 AM, Rüdiger Meier <[hidden email]> wrote:

> On 04/24/2017 04:19 PM, Neal Gompa wrote:
>>
>> Hello,
>>
>> With some guidance from Michael Schroeder, I'd like to propose a few
>> changes to RPM for Factory / Tumbleweed in time for SLE 15.
>>
>> * Backport the --changes option from RPM git master to rpm 4.13.
>
>
> What is the difference to the existing --changelog option?
>

The --changes option shows the time as well as the date. --changelog
only shows the date. Now that RPM can encode the full timestamp,
that's useful information. Upstream wanted it to be a different option
rather than updating --changelog, so it is what it is.

--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Michael Matz
In reply to this post by Neal Gompa
Hi,

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 :) ).
But it's a change that potentially causes quite some disruption, so do the
change in some staging project.  If it should happen for SLE-next as well
(which I think would be a good thing) then it needs to happen soon.
Nevertheless it would be very nice to have this.


Ciao,
Michael.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Neal Gompa
On Mon, Apr 24, 2017 at 12:09 PM, Michael Matz <[hidden email]> wrote:

> Hi,
>
> 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 :) ).
> But it's a change that potentially causes quite some disruption, so do the
> change in some staging project.  If it should happen for SLE-next as well
> (which I think would be a good thing) then it needs to happen soon.
> Nevertheless it would be very nice to have this.
>

I can prepare an SR to Base:System and have it propagate through the
normal Factory merge process (that is, the devel->stage->factory
release scheme). I believe that should suffice to make sure everything
is changed correctly.

--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Ferdinand Thiessen
In reply to this post by Michael Matz
I think /usr/lib suggests 32bit content on x86_64.
And also if there is a standard location, why not use it (I am not sure how common libexec is, but if it is widely used then go for it).

Regards,
Ferdinand

Am 25. April 2017 14:27:30 MESZ schrieb  
>
>What's wrong with /usr/lib/name/? IMO /usr/libexec is redundant.
>
>cu
>Ludwig
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Ruediger Meier
In reply to this post by Michael Matz


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.

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Neal Gompa
On Tue, Apr 25, 2017 at 8:38 AM, Rüdiger Meier <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Michael Matz
In reply to this post by Michael Matz
Hi,

On Tue, 25 Apr 2017, Ludwig Nussel wrote:

> > 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/?

Everything.  lib shall not contain executables.  lib shall not contain
subdirectories.  lib shall contain only libraries.  lib shall contain
_nothing_ on lib64 platforms.

> IMO /usr/libexec is redundant.

20 years of linux distros doing it wrong by overriding perfectly fine
autoconf defaults (caused by the FHS not grasping the concept) makes you
think so.  It is redundant in the same sense that e.g. /usr/include is
redundant; let's put everything into /stuff/ .


Ciao,
Michael.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Ludwig Nussel
Michael Matz schrieb:

> Hi,
>
> On Tue, 25 Apr 2017, Ludwig Nussel wrote:
>
>>> 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/?
>
> Everything.  lib shall not contain executables.  lib shall not contain
> subdirectories.  lib shall contain only libraries.  lib shall contain
> _nothing_ on lib64 platforms.

A pretty radical demand. I guess you have technical insight that
makes you say that? Even the dynamic linker may read libraries from
subdirectories. Also, what about multilib approaches?

>> IMO /usr/libexec is redundant.
>
> 20 years of linux distros doing it wrong by overriding perfectly fine
> autoconf defaults (caused by the FHS not grasping the concept) makes you
> think so.

Perfectly fine defaults like /usr/com? :-) Fedora seems to be rather
lonely in the Linux world by using libexec.

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Neal Gompa
On Wed, Apr 26, 2017 at 5:21 AM, Ludwig Nussel <[hidden email]> wrote:

> Michael Matz schrieb:
>>
>> Hi,
>>
>> On Tue, 25 Apr 2017, Ludwig Nussel wrote:
>>
>>>> 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/?
>>
>>
>> Everything.  lib shall not contain executables.  lib shall not contain
>> subdirectories.  lib shall contain only libraries.  lib shall contain
>> _nothing_ on lib64 platforms.
>
>
> A pretty radical demand. I guess you have technical insight that
> makes you say that? Even the dynamic linker may read libraries from
> subdirectories. Also, what about multilib approaches?
>
>>> IMO /usr/libexec is redundant.
>>
>>
>> 20 years of linux distros doing it wrong by overriding perfectly fine
>> autoconf defaults (caused by the FHS not grasping the concept) makes you
>> think so.
>
>
> Perfectly fine defaults like /usr/com? :-) Fedora seems to be rather
> lonely in the Linux world by using libexec.
>

Fedora isn't the only one using libexec. Mageia does, and several
other offshoots of the Red Hat family do. Slackware and its
derivatives do too. There used to be more before FHS blatantly ignored
the usage of it for many years. Now that it is recognized by FHS, the
offense of having things stuffed into /lib can be eliminated.

As for /usr/com, I'm not sure whether it's right or wrong, but for
better or worse, Linux systems generally assume /usr can be read-only,
so shared state information in /usr is wrong, since that assumes a
portion of /usr is always writable. And for what it's worth, only
autotools assumes shared state is in /usr/com, everything else assumes
/var/lib.

--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [opensuse-factory] Re: [opensuse-packaging] Proposal: Update rpm configuration to fix issues and rationalize configuration

Ludwig Nussel
Neal Gompa schrieb:

> On Wed, Apr 26, 2017 at 5:21 AM, Ludwig Nussel <[hidden email]> wrote:
>> Michael Matz schrieb:
>>> On Tue, 25 Apr 2017, Ludwig Nussel wrote:
>>>>> 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/?
>>>
>>> Everything.  lib shall not contain executables.  lib shall not contain
>>> subdirectories.  lib shall contain only libraries.  lib shall contain
>>> _nothing_ on lib64 platforms.
>>
>> A pretty radical demand. I guess you have technical insight that
>> makes you say that? Even the dynamic linker may read libraries from
>> subdirectories. Also, what about multilib approaches?
>>
>>>> IMO /usr/libexec is redundant.
>>>
>>> 20 years of linux distros doing it wrong by overriding perfectly fine
>>> autoconf defaults (caused by the FHS not grasping the concept) makes you
>>> think so.
>>
>> Perfectly fine defaults like /usr/com? :-) Fedora seems to be rather
>> lonely in the Linux world by using libexec.
>>
> Fedora isn't the only one using libexec. Mageia does, and several
> other offshoots of the Red Hat family do. Slackware and its
> derivatives do too.

We're also partially a Slackware descendant but moved away from
libexec 20 years ago:

$ osc cat openSUSE:Factory gawk gawk.changes|grep -B3 libexec
Sun Apr 13 23:04:29 MEST 1997 - [hidden email]

- add bug-fixes from gnu.utils.bugs
- do not use /usr/libexec anymore

Anyone long enough here to remember why? :-)

> There used to be more before FHS blatantly ignored
> the usage of it for many years. Now that it is recognized by FHS, the

Do we know why it was not part of FHS in the first place? 20 years
plain ignorance seems to be a rather simplistic explanation.
And why was it changed suddenly? Merely documenting existing
practice, accepting that some distros never intended to adopt? Or is
there a greater technical vision now (which one?)

> offense of having things stuffed into /lib can be eliminated.

I don't feel offended at least :-)

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [opensuse-factory] Re: [opensuse-packaging] Proposal: Update rpm configuration to fix issues and rationalize configuration

Jan Engelhardt-4

On Wednesday 2017-04-26 14:05, Ludwig Nussel wrote:
>
>> There used to be more before FHS blatantly ignored
>> the usage of it for many years. Now that it is recognized by FHS, the
>
> Do we know why it was not part of FHS in the first place?

It feels like I have seen it in FHS before (like, 2.2ish), but all the historic
documents still discoverable
  https://www.ibiblio.org/pub/Linux/docs/fhs/ (2.0 and earlier)
  socs.acadiau.ca/~jdiamond/Acadia-Linux-template-tutorial/resources/fhs-2.1.pdf
  http://pathname.com/fhs/ (2.2 and 2.3)

turn out not to mention it. However, the Fedora 14, RHEL 3 and RHEL 6
documentation all make it look like it was part of FHS. Maybe that is where I
picked up…

 https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/s1-filesystem-fhs.html
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-filesystem-fhs.html
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-filesystem.html

The libexec thing appears to be inherited from BSD, as it is not
documented for Solaris. Given Linux always had a tendency to favor sysv
over bsd interfaces, maybe that's why it never got into FHS until 3.0.
Of course that's all just conjecture :)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Michael Matz
In reply to this post by Ludwig Nussel
Hi,

On Wed, 26 Apr 2017, Ludwig Nussel wrote:

> > > What's wrong with /usr/lib/name/?
> >
> > Everything.  lib shall not contain executables.  lib shall not contain
> > subdirectories.  lib shall contain only libraries.  lib shall contain
> > _nothing_ on lib64 platforms.
>
> A pretty radical demand. I guess you have technical insight that makes
> you say that?

It's not so much technical, but as I said there are also no technical
reasons why e.g. /usr/include would be separate, all its content could
just as well be stuffed into /usr/lib.  It's about what conceptually
belongs where, header files to /usr/include, libraries to /usr/lib and
executables called only internally by other tools into /usr/libexec, or
/usr/libexec/$toolname (modules would belong into this category) and
other files associated with a tool into /usr/share.

From there it follows fairly easily that /usr/lib should be empty on a
pure lib64 system.  Also /usr/lib should be able to be mounted noexec, and
everything should continue to work.  One advantage of putting executable
helpers for a tool into libexec, not lib{,64} would be that the path
doesn't depend on architecture bits (as it should be, because for
executables the bitness doesn't matter, for libraries it does).

> Even the dynamic linker may read libraries from subdirectories.

Only if configured in /etc/ld.so.conf or LD_LIBRARY_PATH.

> Also, what about multilib approaches?

What about them?  They're orthogonal to libexec (except in so far as
cleaning up cruft from lib makes multilib approaches easier).


Ciao,
Michael.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [opensuse-factory] Re: [opensuse-packaging] Proposal: Update rpm configuration to fix issues and rationalize configuration

Ruediger Meier
In reply to this post by Ludwig Nussel


On 04/26/2017 02:05 PM, Ludwig Nussel wrote:

> Neal Gompa schrieb:
>> On Wed, Apr 26, 2017 at 5:21 AM, Ludwig Nussel <[hidden email]>
>> wrote:
>>> Michael Matz schrieb:
>>>> On Tue, 25 Apr 2017, Ludwig Nussel wrote:
>>>>>> 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/?
>>>>
>>>> Everything.  lib shall not contain executables.  lib shall not contain
>>>> subdirectories.  lib shall contain only libraries.  lib shall contain
>>>> _nothing_ on lib64 platforms.
>>>
>>> A pretty radical demand. I guess you have technical insight that
>>> makes you say that? Even the dynamic linker may read libraries from
>>> subdirectories. Also, what about multilib approaches?
>>>
>>>>> IMO /usr/libexec is redundant.
>>>>
>>>> 20 years of linux distros doing it wrong by overriding perfectly fine
>>>> autoconf defaults (caused by the FHS not grasping the concept) makes
>>>> you
>>>> think so.
>>>
>>> Perfectly fine defaults like /usr/com? :-) Fedora seems to be rather
>>> lonely in the Linux world by using libexec.
>>>
>> Fedora isn't the only one using libexec. Mageia does, and several
>> other offshoots of the Red Hat family do. Slackware and its
>> derivatives do too.
>
> We're also partially a Slackware descendant but moved away from
> libexec 20 years ago:
>
> $ osc cat openSUSE:Factory gawk gawk.changes|grep -B3 libexec
> Sun Apr 13 23:04:29 MEST 1997 - [hidden email]
>
> - add bug-fixes from gnu.utils.bugs
> - do not use /usr/libexec anymore
>
> Anyone long enough here to remember why? :-)

I guess there is very simple explanation.

Seem's like gawk is using "libexecdir" since gawk-3.0. That was around
1996/97. In the autoconf documentation "libexecdir" was firstly mentioned
around 1994, August (maybe released even later). So I guess that at
this time (1995-1997) first projects slowly started actually using
"libexecdir".

 From the view of a user or distro developer it was probably like: "WTF,
why gawk suddenly introduces such stupid /usr/libexec. We don't need
it. We don't want it. We don't use this!"

Hehe, this issue reminds me a bit about the monkey/ladder experiment
https://i.stack.imgur.com/MyQki.jpg

>> There used to be more before FHS blatantly ignored
>> the usage of it for many years. Now that it is recognized by FHS, the
>
> Do we know why it was not part of FHS in the first place? 20 years
> plain ignorance seems to be a rather simplistic explanation.
> And why was it changed suddenly? Merely documenting existing
> practice, accepting that some distros never intended to adopt? Or is
> there a greater technical vision now (which one?)

Yes, I guess just because major distros never used it. If they wouldn't have
followed freedesktop/systemd then FHS would also look different.

cu,
Rudi

>> offense of having things stuffed into /lib can be eliminated.
>
> I don't feel offended at least :-)
>
> cu
> Ludwig
>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Update rpm configuration to fix issues and rationalize configuration

Thorsten Kukuk
In reply to this post by Neal Gompa
On Wed, Apr 26, Neal Gompa wrote:

> As for /usr/com, I'm not sure whether it's right or wrong, but for
> better or worse, Linux systems generally assume /usr can be read-only,

Which is not correct. FHS says /usr can be read-only, but most Linux
systems cannot scope with that and will report errors.
Only because FHS demands it does not mean developers will take care of
it...
And yes, as I'm currently working on a system with root read-only,
I know about what I'm speaking.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12
Loading...