Steve Greenland <[EMAIL PROTECTED]> immo vero scripsit:
> > How about simply:
> >
> > If your package includes run-time support programs that don't need to
> > be invoked manually by the users, or named in a way that would cause
> > conflicts if placed in $PATH, but are nevertheless require
On 09-May-02, 13:53 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote:
> How about simply:
>
> If your package includes run-time support programs that don't need to
> be invoked manually by the users, or named in a way that would cause
> conflicts if placed in $PATH, but are nevertheless require
* Julian Gilbey <[EMAIL PROTECTED]> [020510 09:59]:
> There is, I have just realised, a middle way, which satisfies your
> concerns and mine. There is an official list, maintained by you, and
> for convenience, the information could be included in policy, with the
> note that the official list can
On Fri, May 10, 2002 at 11:25:33AM +1000, Anthony Towns wrote:
> > For
> > example, when talking about shared and static libraries, there may be
> > exceptional cases where both the shared library and the development
> > parts (headers and static library) live in the same package. Then one
> > wou
On Fri, May 10, 2002 at 03:48:28AM +1000, Anthony Towns wrote:
> > My suggestion for a
> > policy rewrite it to move to the standard RFC uses of MUST and SHOULD,
> > and indication RC-ness in an orthogonal way.
>
> In short, this isn't going to happen. There'll be a separate document,
> maintained
5 matches
Mail list logo
