[opensuse-buildservice] /usr/lib -> /usr/share in build package
Most files in obs-build are put into /usr/lib. This directory is intended only for binaries, but all but one (initvm.`uname -m`) are architecture independent and therefore should go into /usr/share and only initvm.`uname -m` should stay in /usr/lib. I'm willing to create PR to change the location. But it will affect both obs-build and open-build-service. Do you agree with this change? -- Miroslav Suchy, Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tue, Aug 13, 2013 at 03:24:08PM +0200, Miroslav Suchý wrote:
Most files in obs-build are put into /usr/lib. This directory is intended only for binaries, but all but one (initvm.`uname -m`) are
Hi, I know that venerable FHS might not be a valid authority nowadays, but /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or **shell scripts**. http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGAN... IOW $ rpm --eval '%{_libexecdir}' /usr/lib Regards Michal Vyskocil
architecture independent and therefore should go into /usr/share and only initvm.`uname -m` should stay in /usr/lib.
I'm willing to create PR to change the location. But it will affect both obs-build and open-build-service. Do you agree with this change?
-- Miroslav Suchy, Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 08/13/2013 04:53 PM, Michal Vyskocil wrote:
I know that venerable FHS might not be a valid authority nowadays, but
/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or **shell scripts**.
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGAN...
*not intended to be executed by shell scripts* - which does not means that shell script are allowed there. And full quote is: /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. [22] See footnote 22 http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1389 [22] Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share. -- Miroslav Suchy, Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 8/13/2013 11:57 AM, Miroslav Suchý wrote:
On 08/13/2013 04:53 PM, Michal Vyskocil wrote:
I know that venerable FHS might not be a valid authority nowadays, but
/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or **shell scripts**.
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGAN...
*not intended to be executed by shell scripts* - which does not means that shell script are allowed there.
And full quote is: /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. [22]
See footnote 22 http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1389 [22] Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share.
To me that means that an icon goes in /usr/share and a shell function goes in /usr/lib. What exactly are you proposing to change and why? -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 08/13/2013 09:33 PM, Brian K. White wrote:
To me that means that an icon goes in /usr/share and a shell function goes in /usr/lib.
Nope. FHS is saying: if it is binary (or library), which should not be executed directly by user, it should got into /usr/lib. But if it is architecture independent (eg. perl/python script) it should go to /usr/share. Yes, icons are arch independent so it should go to /usr/share as well. -- Miroslav Suchy, Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Miroslav Suchý <msuchy@redhat.com> writes:
FHS is saying: if it is binary (or library), which should not be executed directly by user, it should got into /usr/lib. But if it is architecture independent (eg. perl/python script) it should go to /usr/share.
That doesn't make sense. Whether an executable is implemented with a scripting language or a compiled language should be transparent to the caller. There should not be a requirement to move an executable between libexecdir and datadir just because the implementation language changes. All user-callable scripts are also located in bindir, not datadir. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 08/14/2013 12:42 PM, Andreas Schwab wrote:
That doesn't make sense.
Rationale stated by FHS: This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS.
All user-callable scripts are also located in bindir, not datadir. That is because user-callable scripts are in /usr/bin, which is mixture of arch dependent files and arch independent files, which can not be split.
I just want to package the build script and one of the task is to get rid of rpmlint errors. And rpmlint say: files in /usr/lib contains just non-binary files, therefore it should go /usr/share. So I'm just following. -- Miroslav Suchy, Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Miroslav Suchý <msuchy@redhat.com> writes:
On 08/14/2013 12:42 PM, Andreas Schwab wrote:
That doesn't make sense.
Rationale stated by FHS: This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted.
That doesn't contradict my point. It only says that datadir must not contain architecture-dependent files, but doesn't forbid putting scripts in libexecdir. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wednesday 2013-08-14 12:04, Miroslav Suchý wrote:
On 08/13/2013 09:33 PM, Brian K. White wrote:
To me that means that an icon goes in /usr/share and a shell function goes in /usr/lib.
Nope. FHS is saying: if it is binary (or library), which should not be executed directly by user, it should got into /usr/lib. But if it is architecture independent (eg. perl/python script) it should go to /usr/share. Yes, icons are arch independent so it should go to /usr/share as well.
Blame FHS for creating this confusion. And then blame distros actually implementing that. libexecdir used to be in a past FHS version, and originally(?) came from the GNU "HS" - if you want to call it such. Fedora still has libexecdir thankfully. And it's quite clear what it was: * libexecdir: auxiliary programs not to be directly executed by the user. Follows /usr/bin, i.e. "just one bitness". * libdir: arch-dependent pieces, may have multiple bitnesses arranged in some arbitrary fashion (Debian multiarch looks good; Perl is one of the layouts used historically) * datadir: arch-independent, no questions asked. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 8/14/2013 8:18 AM, Jan Engelhardt wrote:
On Wednesday 2013-08-14 12:04, Miroslav Suchý wrote:
On 08/13/2013 09:33 PM, Brian K. White wrote:
To me that means that an icon goes in /usr/share and a shell function goes in /usr/lib.
Nope. FHS is saying: if it is binary (or library), which should not be executed directly by user, it should got into /usr/lib. But if it is architecture independent (eg. perl/python script) it should go to /usr/share. Yes, icons are arch independent so it should go to /usr/share as well.
Blame FHS for creating this confusion. And then blame distros actually implementing that.
libexecdir used to be in a past FHS version, and originally(?) came from the GNU "HS" - if you want to call it such. Fedora still has libexecdir thankfully. And it's quite clear what it was:
* libexecdir: auxiliary programs not to be directly executed by the user. Follows /usr/bin, i.e. "just one bitness". * libdir: arch-dependent pieces, may have multiple bitnesses arranged in some arbitrary fashion (Debian multiarch looks good; Perl is one of the layouts used historically) * datadir: arch-independent, no questions asked.
The arch-independent part sort of makes sense, but a shell (or other) function isn't static and it isn't data. The "it's arch-independent" aspect doesn't override the "it's active code not mere data" aspect. Or, if it DOES, then why doesn't that apply everywhere? Consider it the same as shell or other scripts that you DO execute directly. They are just exactly as arch-independent, yet you still put them in /usr/bin not in /usr/share/bin Now that I say that. I have no strong reason why there should not be a defined arch-independent bin. Maybe not /usr/share/bin but something. So maybe we could invent that. But at the moment that's not the way it works. And so I think we should treat a scripting library the same as an elf library, for the same reason we treat a script executable the same as an elf executable. -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Dienstag, 13. August 2013, 15:24:08 schrieb Miroslav Suchý:
Most files in obs-build are put into /usr/lib. This directory is intended only for binaries, but all but one (initvm.`uname -m`) are architecture independent and therefore should go into /usr/share and only initvm.`uname -m` should stay in /usr/lib.
I'm willing to create PR to change the location. But it will affect both obs-build and open-build-service. Do you agree with this change?
Hm, I am just frightend. We have it that way since a long, long time and I have actually absolute no idea what we break with that. We can try the move, maybe we can create some compat symlinks from /usr/lib/build/Build to /usr/share/... ? not so easy with rpm, but doable via %post hacks :/ hm, thinking again, I want to sleep over that for a night :) If this blocks you, we may can do a compromise and just package it for fedora that way. There we do not need to fear backward compatibility problems. We just would need two pathes then in OBS code trying both locations. What do you think about that? bye adrian -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 08/13/2013 05:30 PM, Adrian Schröter wrote:
If this blocks you, we may can do a compromise and just package it for fedora that way. There we do not need to fear backward compatibility problems. We just would need two pathes then in OBS code trying both locations.
What do you think about that?
It does not blocks me right now. And I can easily make this change just for Fedora. And if there will be no problem in Fedora, I can then submit it to core OBS. Sounds like a plan. -- Miroslav Suchy, Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (6)
-
Adrian Schröter -
Andreas Schwab -
Brian K. White -
Jan Engelhardt -
Michal Vyskocil -
Miroslav Suchý