[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#146023: [PROPOSAL]: "libexec", or use of "lib" for binaries in lib* packages



wHi,

         I think that we did not quite reach a consensus or a final
  wording on this, and at least one point was left unaddressed. I am
  also not fully convinced we need this as policy (as opposed to
  something in developers reference), but I am not going to oppose
  this.
 ======================================================================
  --- policy.sgml.orig    Tue May  7 01:06:15 2002
  +++ policy.sgml Tue May  7 01:11:23 2002
  @@ -5598,6 +5598,15 @@
          </p>

  +        <p>
  +         If your package includes run-time support programs that
  +         do not need to be invoked manually by users, but are
  +         nevertheless required  for the package to function, then it
  +         is recommended that these programs are placed
  +         (if they are binary) in a subdirectory of
  +         <file>/usr/lib</file>, preferably under
  +         <file>/usr/lib/</file><var>package-name</var>.
  +         If the program is architecture independent, the
  +         recommendation is for it to be placed in a subdirectory of
  +         <file>/usr/share</file> instead, preferably under
  +         <file>/usr/lib/</file><var>package-name</var>.
  +       </p>
  +
         <p>
            If you have several shared libraries built from the same
            source tree you may lump them all together into a single
            shared library package, provided that you change all of
 ======================================================================

         I think I have addressed all outstanding issue in the above
  patch;

    a) it shows a predilection for a directory named for the package,
       but does not mandate it
    b) Since this is a new requirement, it starts off as a
       recommendation (after all, this was originally touted merely as
       "best practice", not as something required for interoperability)
    c) It also discusses arch independent modules, and adds similar
       language for that.
         I am looking for seconds for this modified proposal, and as
  always, am open for corrections and improvement of the language.

         manoj
-- 
Are we THERE yet?  My MIND is a SUBMARINE!!
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: