<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 05/26/2016 02:38 PM, Lennart
Poettering wrote:<br>
</div>
<blockquote cite="mid:20160526143818.GB16544@gardel-login"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> </span>On 05/26/2016 09:36 AM, Lennart Poettering wrote:
<span class="moz-txt-citetags">> </span>
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> ></span>/usr is for the OS vendor really.
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>Given that it's generally expected and wanted that application developers
<span class="moz-txt-citetags">> </span>follow the os vendors packaging guideline and rules as possible in
<span class="moz-txt-citetags">> </span>distribution and many 3rd party repositories reflect that, I have to ask
<span class="moz-txt-citetags">> </span>what's your reasoning for limit this to OS vendor only?
</pre>
</blockquote>
<pre wrap="">It's a shared namespace. Distros have enough problems already making
sure that no two packages own the same names for their binaries,
libraries, ... If you now allow multiple unrelated parties to all dump
their own stuff in there, then you can only fail with that.</pre>
</blockquote>
<br>
If 3rd party application providers aren't following the vendor OS
packaging guidelines well then that OS vendors will have that mess
on it's hand ( or rather that unfortunate administrator that install
said application or application stack ) and that pretty much can be
said about anyone or anything not following upstream or "standards"
in general so such scenarios are doomed to fail regardless of any
effort in trying to prevent that .<br>
<br>
<blockquote cite="mid:20160526143818.GB16544@gardel-login"
type="cite">
<pre wrap="">
I think /opt is deeply flawed and not thought to the end, but the one
thing it does get right is that every vendor package gets its own dir
below /opt, thus dealing with the namespacing problems at least a bit.</pre>
</blockquote>
<br>
That's not always the case and it's not guaranteed that 3rd party
even follows that, some choose to use /srv instead of /opt and some
choose to place their things anywhere <sigh>. <br>
<br>
If those glorified "holy unix bible" writers in last century could
have thought ahead, they would have created /usr/vendor at the same
time they created /usr/local and everyone would have adapted to that
already but here we are on a new century with file system<em></em><span
class="st"><em></em></span><span class="st"><em> </em></span>hierarchy
mess on our hand, which hopefully in not to distant future
application containers will take care of for us since fixing this
requires joint collaborated effort of ( at least major )
distributions and them implementing it at the same time and that's
not going to happen anytime soon, if ever since some of those
distribution hold so deer into their false sense of "independence"
or deliberately are deviating and forking themselves from one
another due to "competition". <br>
<br>
JBG<br>
<br>
<br>
</body>
</html>