* RFD: --enable-bindir-path ?
@ 2018-08-26 17:54 L A Walsh
2018-08-30 8:45 ` Karel Zak
0 siblings, 1 reply; 6+ messages in thread
From: L A Walsh @ 2018-08-26 17:54 UTC (permalink / raw)
To: util-linux
Was wondering about the addition of an "enable-bindir-path" which would
only use
paths with /bin instead of /usr/bin for setups where /usr/bin -> /bin
(like cygwin who mounts /bin and /lib on /usr/bin and /usr/lib -- using
mounts instead of symlinks). The've had that since the beginning with
nothing being
installed in /usr/bin or /usr/lib.
Was also wondering why that wasn't chosen as a default for merging, since
/bin and /lib are almost always on the root file system so they are always
there, versus /usr/{bin,lib{,64}} which may need to be mounted before it can
be used...if it can't be mounted, having things in /bin & /lib pointed
to /usr won't work so well.
Anyway, just thought the option would be easy enough apart from other
issues(?).
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: RFD: --enable-bindir-path ? 2018-08-26 17:54 RFD: --enable-bindir-path ? L A Walsh @ 2018-08-30 8:45 ` Karel Zak 2018-08-31 22:55 ` L A Walsh 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2018-08-30 8:45 UTC (permalink / raw) To: L A Walsh; +Cc: util-linux On Sun, Aug 26, 2018 at 10:54:49AM -0700, L A Walsh wrote: > Was wondering about the addition of an "enable-bindir-path" which would only > use > paths with /bin instead of /usr/bin for setups where /usr/bin -> /bin (like > cygwin who mounts /bin and /lib on /usr/bin and /usr/lib -- using mounts > instead of symlinks). The've had that since the beginning with nothing > being > installed in /usr/bin or /usr/lib. So for this use-case /usr should be ignored at all, right? What about PATH setting? Is it also without /usr? What about man pages, docs? I have nothing against this feature, but question is if it's important enough to implement and support it ;-) > Was also wondering why that wasn't chosen as a default for merging, since > /bin and /lib are almost always on the root file system so they are always > there, versus /usr/{bin,lib{,64}} which may need to be mounted before it can > be used...if it can't be mounted, having things in /bin & /lib pointed > to /usr won't work so well. I think originally /usr was also on the same FS as /{bin,lib,...}. Anyway, now this no issue as we use initram images where is all stuff that is necessary to assemble usable hierarchy of filesystems (including RAIDs, NFS moutpoints, etc.) Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFD: --enable-bindir-path ? 2018-08-30 8:45 ` Karel Zak @ 2018-08-31 22:55 ` L A Walsh 2018-09-03 10:17 ` Karel Zak 0 siblings, 1 reply; 6+ messages in thread From: L A Walsh @ 2018-08-31 22:55 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux Karel Zak wrote: > On Sun, Aug 26, 2018 at 10:54:49AM -0700, L A Walsh wrote: > >> Was wondering about the addition of an "enable-bindir-path" which would only >> use >> paths with /bin instead of /usr/bin for setups where /usr/bin -> /bin (like >> cygwin who mounts /bin and /lib on /usr/bin and /usr/lib -- using mounts >> instead of symlinks). The've had that since the beginning with nothing >> being >> installed in /usr/bin or /usr/lib. >> > > So for this use-case /usr should be ignored at all, right? What about PATH > setting? Is it also without /usr? What about man pages, docs? > ---- The use case for enable-usrdir-path is for cases where /bin->/usr/bin /lib->/usr/lib, /lib64->/usr/lib, sbin->/usr/sbin, conversely, the opposite would be where bin are in /bin and /usr/bin is a symlink to /bin, and same for the libdirs and sbin. There is nothing in switch description about /doc, or /man being mounted on /usr/<equiv>, so why would one move those around? > I have nothing against this feature, but question is if it's important > enough to implement and support it ;-) > --- Well the sbin dirs are separate in cygwin, but /usr/bin is copy /bin same for the lib dir. It's really not that much to implement. Only thing it means is that if /usr is a separate partition, then during boot, all your files in /bin, lib, lib64/ sbin...will be on the root, while and boot can continue. While if all the libs+binaries are /usr, it's hard to mount. So the use case is ensuring the system will boot? > >> Was also wondering why that wasn't chosen as a default for merging, since >> /bin and /lib are almost always on the root file system so they are always >> there, versus /usr/{bin,lib{,64}} which may need to be mounted before it can >> be used...if it can't be mounted, having things in /bin & /lib pointed >> to /usr won't work so well. >> > > I think originally /usr was also on the same FS as /{bin,lib,...}. > ---- Depends on what you mean by "originally", but back before linux, originally there was no /usr, it came later for /usr files and home dirs. On it were application binaries for users, but binaries that were not required for boot. > Anyway, now this no issue as we use initram images where is all > stuff that is necessary to assemble usable hierarchy of filesystems > (including RAIDs, NFS moutpoints, etc.) > > Karel > ---- Who is this 'we' kimosami? ;^) Not me, nor anyone following the systemd recommendations for boot speed. My kernel is on a disk partition named 'boot' and it transfers control to the 'root' partition that brings up HW, disks and network. After that the rest of the system is brought up. Everything worked well until libs needed for 'mount' started appearing on /usr. If you had everything on a ram disk that was needed for boot, but then the libs for some of the programs were out on the hard disk, the ram disk would have a hard time proceeding as well. I don't have a different or separate /usr/{{s,}bin,lib{,64}} on a ram disk as exists on my my hard disk, and /usr is usually too large for a ram disk image. So now how would one know when another part of some boot program had been split off and put out on the disk /usr/lib? Hopefully not by waiting until it fails because at that point it's a bit too late. Does that answer your questions? Cheers! -Linda ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFD: --enable-bindir-path ? 2018-08-31 22:55 ` L A Walsh @ 2018-09-03 10:17 ` Karel Zak 2018-09-04 9:41 ` Karel Zak 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2018-09-03 10:17 UTC (permalink / raw) To: L A Walsh; +Cc: util-linux On Fri, Aug 31, 2018 at 03:55:09PM -0700, L A Walsh wrote: > conversely, the opposite would be where bin are in /bin and /usr/bin is > a symlink to /bin, and same for the libdirs and sbin. > > There is nothing in switch description about /doc, or /man being mounted > on /usr/<equiv>, so why would one move those around? just asking to be sure > > I have nothing against this feature, but question is if it's important > > enough to implement and support it ;-) > --- > Well the sbin dirs are separate in cygwin, but /usr/bin is copy /bin > same for the lib dir. It's really not that much to implement. Only thing > it means is that if /usr is a separate partition, then during boot, > all your files in /bin, lib, lib64/ sbin...will be on the root, while and > boot can continue. While if all the libs+binaries are /usr, it's hard to > mount. So the use case is ensuring the system will boot? There is so many ways how to keep different groups of users happy... ;-) I don't care which is the best and I really don't making such decisions. The defaults are usually about mainstream distros, but we don't ignore another use-cases. If you have good use-case then I'm ready to support it (well, if the change has not bad impact to the current behavior). > > Anyway, now this no issue as we use initram images where is all > > stuff that is necessary to assemble usable hierarchy of filesystems > > (including RAIDs, NFS moutpoints, etc.) > > > > Karel > ---- > Who is this 'we' kimosami? ;^) > > Not me, nor anyone following the systemd recommendations for boot > speed. Blame systemd is good sport ;-), but in this case... we have had ramdisks with usable mount(8) and another stuff for complicated setups many years before systemd... > Everything worked well until libs needed for 'mount' started appearing > on /usr. If you had everything on a ram disk that was needed for boot, > but then the libs for some of the programs were out on the hard disk, > the ram disk would have a hard time proceeding as well. The current util-linux upstream default is to install mount(8) to $bindir and --enable-usrdir-path is not enabled by default. The default is to install libmount also to /lib if $libdir is a different to $usrlib_execdir. All you need is to specify --libdir=/lib $ ./configure --disable-makeinstall-chown --disable-makeinstall-setuid --libdir=/lib $ make install DESTDIR=/home/projects/util-linux/util-linux/xxx $ find /home/projects/util-linux/util-linux/xxx/lib /home/projects/util-linux/util-linux/xxx/lib /home/projects/util-linux/util-linux/xxx/lib/libmount.so.1 /home/projects/util-linux/util-linux/xxx/lib/libblkid.so.1.1.0 /home/projects/util-linux/util-linux/xxx/lib/libsmartcols.so.1.1.0 /home/projects/util-linux/util-linux/xxx/lib/libuuid.so.1.3.0 /home/projects/util-linux/util-linux/xxx/lib/libfdisk.so.1 /home/projects/util-linux/util-linux/xxx/lib/libmount.so.1.1.0 /home/projects/util-linux/util-linux/xxx/lib/libfdisk.so.1.1.0 /home/projects/util-linux/util-linux/xxx/lib/libuuid.so.1 /home/projects/util-linux/util-linux/xxx/lib/libsmartcols.so.1 /home/projects/util-linux/util-linux/xxx/lib/libblkid.so.1 So, technically your use-case is already supported, although I agree that it is not user-friendly and maybe explicit "enable-bindir-path" would be better. [The default install to $usrlib in Makefiles is autotools-ism around $prefix and we respect this woodoo ;-) I'd like to not change it because it always introduces new issues and the current solution seems well tested and it seems stable for years. I guess all we need is to make it more usable by ./configue. Maybe from long term point of view the answer is "meson" :-) ] Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFD: --enable-bindir-path ? 2018-09-03 10:17 ` Karel Zak @ 2018-09-04 9:41 ` Karel Zak 2018-09-07 2:52 ` L A Walsh 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2018-09-04 9:41 UTC (permalink / raw) To: L A Walsh; +Cc: util-linux On Mon, Sep 03, 2018 at 12:17:25PM +0200, Karel Zak wrote: > $ ./configure --disable-makeinstall-chown --disable-makeinstall-setuid --libdir=/lib I did a small improvement for systems where the default is /lib64, so now --libdir=/lib should be unnecessary to install to /bin and /lib if you follow the default settings. Note that if you set --prefix or change any default setting than is probably better to explicitly specify all the directories. For example on Fedora we use ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu \ --program-prefix= --disable-dependency-tracking --prefix=/usr \ --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin \ --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include \ --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var \ --sharedstatedir=/var/lib --mandir=/usr/share/man \ --infodir=/usr/share/info --disable-assert \ --with-systemdsystemunitdir=/usr/lib/systemd/system \ --disable-silent-rules --disable-bfs --disable-pg --enable-chfn-chsh \ --enable-usrdir-path --enable-write --enable-raw --with-python=3 \ --with-systemd --with-udev --with-selinux --with-audit --with-utempter \ --disable-makeinstall-chown to get full control. The option --enable-usrdir-path has been introduced to get proper $PATH. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFD: --enable-bindir-path ? 2018-09-04 9:41 ` Karel Zak @ 2018-09-07 2:52 ` L A Walsh 0 siblings, 0 replies; 6+ messages in thread From: L A Walsh @ 2018-09-07 2:52 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux On 9/4/2018 2:41 AM, Karel Zak wrote: Yeah, configure can be so tedious to use sometimes. I set basic locations and the call common scripts to propagate settings as defined in configure. So specific tools will get some specific paths, and I try to ensure the rest are set accordingly. I try to default a bunch but based on previous settings, like (very truncated list): : ${exec_prefix:=${eprefix}} : ${bits:=64} : ${bindir=${eprefix}bin} ... : ${localstatedir:=${prefix}var} : ${includedir:=${exec_prefix}include} Finally..I expand all the path stuff if the associated var is set declare -a path_ops=( ${prefix:+--prefix=$prefix} ${exec_prefix:+--exec-prefix=$exec_prefix} ${sharedstatedir:+--sharedstatedir=$sharedstatedir} ${sysconfdir:+--sysconfdir=$sysconfdir} ) Result is almost all of the paths being set... I keep all the above in a common location. For all the option toggling, I use 4 arrays: enable, disable, with and without, like: declare -a enable=( readline select single-help-strings ) declare -a disable=(nls ) declare -a with=( gnu-ld ) declare -a without=() then below (config_ops already has path_ops rolled in): for action in enable disable with without; do for op in $(eval echo "\${$action[@]}") ; do config_ops+=( $(echo "--$action-$op") ) done done anyway -- some Q's on the versioning, but separate email... ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-09-07 2:52 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-26 17:54 RFD: --enable-bindir-path ? L A Walsh 2018-08-30 8:45 ` Karel Zak 2018-08-31 22:55 ` L A Walsh 2018-09-03 10:17 ` Karel Zak 2018-09-04 9:41 ` Karel Zak 2018-09-07 2:52 ` L A Walsh
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).