bind-9.11.0-P2 on Debian 9.0 (stretch)

[Reindl Harald]

Am 26.01.2017 um 19:31 schrieb Dennis Clarke:
>>> 1) OpenSSL dependency dance
>>>
>>> I removed OpenSSL 1.1 and compiled OpenSSL 1.0.2e from source
>>
>> You'll probably have better luck installing Debian's libssl1.0-dev and
>> related packages, rather than installing it yourself. Plain libssl-dev in
>> Stretch is OpenSSL 1.1.
>>
>> If you install stuff yourself from source then it is particularly unwise
>> to put it in /usr where it'll collide with files managed by dpkg - put it
>> in /usr/local or /opt.
>>
> I have always been amused by the defacto approach of Linux people
> who compile software and install it into /usr/local as a way to keep
> non-vendor software outside of /usr.  Given that /usr/local is *inside*
> the /usr tree of course

but it don't collide with the package manager which is the whole point 
and so dunno what you find amusing at all

http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html

/usr/local
The original idea behind '/usr/local' was to have a separate ('local') 
'/usr' directory on every machine besides '/usr', which might be just 
mounted read-only from somewhere else. It copies the structure of 
'/usr'. These days, '/usr/local' is widely regarded as a good place in 
which to keep self-compiled or third-party programs. The /usr/local 
hierarchy is for use by the system administrator when installing 
software locally. It needs to be safe from being overwritten when the 
system software is updated. It may be used for programs and data that 
are shareable amongst a group of hosts, but not found in /usr. Locally 
installed software must be placed within /usr/local rather than /usr 
unless it is being installed to replace or upgrade software in /usr.

>  The POSIX and XPG4 approach has always been to provide some real
> separation and install software in /opt/{vendor_name} with the config
> files place under the /etc tree at /etc/opt/{vendor_name}

nothing different with /usr/local (it has the same hierarchy with bin, 
sbin, etc) and there are additional good reasons to use it because it 
has the same protections with ProtectSystem=true from get compromised 
(on modern systems /sbin and /bin are just symlinks to /usr/sbin and 
/usr/bin)

https://www.freedesktop.org/software/systemd/man/systemd.exec.html

ProtectSystem=
Takes a boolean argument or the special values "full" or "strict". If 
true, mounts the /usr and /boot directories read-only for processes 
invoked by this unit. If set to "full", the /etc directory is mounted 
read-only, too. If set to "strict" the entire file system hierarchy is 
mounted read-only, except for the API file system subtrees /dev, /proc 
and /sys

> created ELF file binaries. However the folks in the Debian project and
> many other Linux distro projects often release software to the world
> wherein there is no RPATH or RUNPATH data in the ELF dynamic section
> and thus the libs needed are left to the runtime linker to sort out. In
> this case they could be from where ever the user decides and if they
> very dangerously use LD_LIBRARY_PATH then an over ride may be enforced

https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath

but that's completly offtopic, the whole reason why you never use /usr 
as prefix for your own builds is that at any time in the future 
something may introduce a new dependency and with random updates your 
self built stuff get overwritten and in case something just pulls 
libraries it will get *destroyed* because your unmanaged executable 
stuff is still present in the version you did "make install" but it's 
librarie sgot overwritten by the package manager which has no clue and 
needs not have a clue that somebody did overwrite randomly stuff where 
he ha no business to do so

> The point of ALL of the above is that users of open software should
> always have the freedom to build software on their own computers from
> sources as they please and to install the results of their work as they
> please.  However a bit of caution should be used in the placement of
> the resultant executables and the libraries such that they do not
> affect the runtime characteristics of their distro.  However the freedom
> is there and the sources exist for very good reasons and if a user makes
> the choice to dance in a minefield then by all means let them. However a
> caution sign should be posted on the outer edge with some fine print
> which says "you have the freedom to do so but here are some guidelines."

yes, you have the freedom to intall whatever you want where you want, 
but the problem