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