Re: OF: community packages depending on external packages?

[Mike Miller]

On Tue, Sep 03, 2019 at 11:42:23 +0200, Olaf Till wrote:
> Hi,
> 
> in recent package release submissions, the issue came up whether
> OF packages in the "community" category should be allowed to depend on
> packages in the "external" community.
> 
> I think not. The "community" category was meant for a tight connection
> with the development of core Octave. For this, our developer community
> was meant to have control over the "community" packages. This control
> is necessary, among others, for namespace issues.

I think yes, community packages should be allowed to depend on external
packages. Not unconditionally, but after considering the specifics of
the package and the dependency. I agree with the rest of this paragraph.

> "External" packages, on the other hand, are under the sole control of
> their individual maintainers. Sometimes, they indirectly depend on
> m-code developed only for Matlab.
> 
> If "community" packages depend on "external" packages, they depend on
> m-code which is not under the cotrol of our developer community. I
> think this would be a mistake.

If a community package contains C++ code that links with an external
library, for example GSL or MPFR, then it also depends on code which is
not under the control of the Octave Forge developer community. The
miscellaneous community package contains a function that depends on the
GNU units external program. These scenarios seem similar to me and
should all be considered and reviewed critically with the possibility of
being accepted as community packages.

Can you explain why you think that depending on externally developed
m-file functions would be unacceptable for a community package, but
depending on externally developed C or C++ functions or programs would
be acceptable?

-- 
mike

signature.asc
Description: PGP signature