RFD: --enable-bindir-path ?

RFD: --enable-bindir-path ?

[L A Walsh]

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(?).

Re: RFD: --enable-bindir-path ?

[Karel Zak]

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

Re: RFD: --enable-bindir-path ?

[L A Walsh]

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

Re: RFD: --enable-bindir-path ?

[Karel Zak]

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

Re: RFD: --enable-bindir-path ?

[Karel Zak]

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

Re: RFD: --enable-bindir-path ?

[L A Walsh]

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...