From owner-freebsd-questions@freebsd.org Fri Sep 13 05:16:14 2019 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2D98DE5991 for ; Fri, 13 Sep 2019 05:16:14 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46V3l10NqYz48wB for ; Fri, 13 Sep 2019 05:16:12 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([178.5.234.134]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPA (Nemesis) id 1M2w0K-1i7Y0h2w96-003M94; Fri, 13 Sep 2019 07:16:07 +0200 Date: Fri, 13 Sep 2019 07:16:06 +0200 From: Polytropon To: Jim Trigg Cc: freebsd-questions@freebsd.org Subject: Re: A modest hier proposal Message-Id: <20190913071606.00aa3d63.freebsd@edvax.de> In-Reply-To: References: Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:LQLTCwn1sjqGAjkzw9XqmziKaDBqA2a9Pd9nzmEPX4+H5fsTBMC R8hSUm8IRNclm6XUZTBTJa1Tha++fyn0aDqAR3RwR2R+qy0R4P9n9gC75Yb5FSz5/ySddmn /hKDS5AY9l3YHQQEZS9GmS9b0/lh+DQiBb91vLAXb8l33HYop3ckcvMp3SxqbQlZsUJGnl3 FpbYkLsAoQCgoZI7t9v4A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:t2CE/5eopHg=:WK+ToHyB8r/Kyqj4ADFn78 9W4WrgsD+T++s14sjEBZhva2w5OlOn4Qv2Ej2LoZIPFhcJt5D54IG8l1I5RvI97GcUWICW4x8 Q4pDZa7F1p2fBw1qufOp0nriwrV0AR4IF/VIOcQ9tFi5hS91+Ttpf9j2za71zLKPvbC8VIudq 84wEUWAlM/RqepTB6d9gzDwEMA0/DhXv1Js/0bAb96kJk/nIT9OUO/jXjzdLBOSrv26TFWHTr z/K1izYWGUNe0fJwh6tUbLXXm/wHNWZ9G2FBARJJJxGfTgtUU8S/fIIyyowEJ4y/l3JZzMDqd dR9/T+qz0ZTXM7clWb0c9yUUTw5DoOzYk7DZwjXcJwXqIXtD+HTJBXa8KUpGg+Bla7jz56/+X SfAoikOdZoW1SJPnZLnvs+lR0nGuGloai+mmendj4BIc+o54JD0ERKogbaGtfbq3cIr+UOVGv yUniF/LBkXR1ZcM6bL/hYwgIKC0MTFcLataNOGfa8gi0BlWaOjVGiYPS2qt5ahvDPGgK+chsR 7l1onxSn3FMhpbzBCIzuBJOnb9G/WmObgi1beAtgD2D4wmTKn2AlLay9kdV2pMDyyqpNZ7Fae +BCDY2ZHPMT15Uijp6zen+Aodzg9gGy7WHTzy4BbNOVAOj7EDNWvVe49B+RZxDYFk0bwKsfkh ARHmkqrugGiqPh6k+f8IW9dMdbpd3DAC+4h/uhU9lkca7Vs8GPgcDzb725IGyucjNrmcWWvfB 0Y+FMyh7B9zSOXrl7pzU161QoFQCHmskjZYWK6kVD5e5k9tX+NskDxnKrVeoV03W/QdP/W+xr lTuNG90ZWzE/N/l6kgOt2Yu9v+krqS9dcIUFbr55VPfE8G2cBaF/xET5823EluC03QUtno4q9 XwAZPtVOpRd2XsrZUJK61jgyehlum87KuXfI7tnps= X-Rspamd-Queue-Id: 46V3l10NqYz48wB X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.126.134) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.86 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[134.234.5.178.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.93)[0.935,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.995,0]; RCVD_IN_DNSWL_NONE(0.00)[134.126.227.212.list.dnswl.org : 127.0.5.0]; MID_CONTAINS_FROM(1.00)[]; R_SPF_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[134.126.227.212.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.53)[ip: (1.90), ipnet: 212.227.0.0/16(-1.37), asn: 8560(2.15), country: DE(-0.01)] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 05:16:14 -0000 On Thu, 12 Sep 2019 23:50:40 -0400, Jim Trigg wrote: > I recommend we reframe the directory structure. Since I'm sure I will > get no support for merging the existing / and /usr trees to put all base > items in / (/bin, /etc, /lib, /libexec, /share, /sbin), [...] The structure documented in "man 7 hier" covers both historical aspects and modern requirements. The status quo is a consensus of rules and considerations, as is the naming of things. > [...] I'm suggesting > the following: > > /usr/local -> /pkg > Explicitly define /opt for third-party software that is not in > packages/ports. Well, /opt is a Linuxism, and historically a Solarism, Solarisism, which is explicitely not covered by FreeBSD definitions. Some users use it to manage "non-ports 3rd party software" totally independently from the rest of the system. Sometimes, /opt/bin exists and is part of $PATH, and contains "call wrappers" for /opt/, as there is no structure defined for /opt - unlike for /usr/local, which more or less replicates the top level structire of the OS, to be used by 3rd party software installed from ports, e. g., /usr/bin /usr/local/bin -> program executables /usr/lib /usr/local/lib -> libraries /usr/libexec /usr/local/libexec -> daemons /usr/share /usr/local/share -> shared objects, data /etc /usr/local/etc -> configuration Programs are encouraged to use those directories. This is a recommendation not always followed... ;-) The difference between / and /usr/ is again a historical thing: Things that are required to get single-user mode up and running, and things that are required for everything that leads to more advanced modes, like multi-user, or graphical. Also partitioning (i. e., having parts of the OS on different partitions that were actually different disks) originates from a time where disk capacity was too low to hold the full OS, so you'd have / on one disk to get the OS up and running, and /usr/local on a different disk for all the 3rd party software the system runs - so the OS could get into a fully functional state without /usr/local being present. You could even swap different /usr/local disks (to revert to an older state or to experimentally try new software). Of course, disk size is not a concern today - as long as you don't enter the embedded space where you even want to have things separated by "is read-only" and "can be writte to", or "can be slow, is used only once" and "needs to be faster, is used all the time". Still using partitions (no matter of using ZFS or UFS) can have advantages, like preventing /tmp from filling the whole disk from some runaway process, or setting specific flags like noexec on a partition for user data like /home where you explicitely want to prevent the user from executing their own stuff. > Explicitly define /local for locally developed software that has not > been packaged as a port/package. That's what people tend to use /opt for, as it does basically let them do what they want - no rules. :-) Of course, it's also possible to use "user-locally developed" software from inside a user's home directory, where ~/bin is often present, and ~/.config is used by some programs. > This leaves us with five areas: > /{bin,etc,lib,libexec,share,sbin} - base software > /usr/{bin,etc,lib,libexec,share,sbin} - base software > /pkg/{bin,etc,lib,libexec,share,sbin} - ports/packages > /opt/{bin,etc,lib,libexec,share,sbin} - third-party software that is not > in ports/packages > /local {bin,etc,lib,libexec,share,sbin} - locally developed software > that has not yet been formalized into a port/package (with symlink from > /usr/local?) Interesting approach, but I think this is not going to happen. I know certain Linux distributions tried to suggest a unified layout for to be shared by all Linusi, but that didn't come true, likewise /Programs, /Data, /ConfigurationAndSettings, and so on. The general rule is: Everything under / belongs to the OS. 3rd party software that is managed by pkg is entirely in /usr/local, and if there should be anything else, it can go to /opt. /home is for users' stuff, site rules might apply. Do you remember PC-BSD (now TrueOS) and their packaging system? They did something comparable: Every program gets its own directory subtree with all stuff belonging to that program (plus its dependencies) in only that directory subtree, with a "caller script" in a directory that is in $PATH? I don't know if they still do that... In my opinion, things will stay as they currently are - not entirely perfect, but understandable and predictable as soon as you have successfully understood the rules and considerations. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...