[M3devel] It works!

[Olaf Wagner]

On Wed, 03 Jun 2015 11:54:50 +0200
John Marino <adacore at marino.st> wrote:

> On 6/3/2015 11:30, Jay K wrote:
> > I believe people typically install to /usr/local/cm3 instead of /usr/local.
> > There is a philosophical problem here in terms of setup file system
> > layout. /<packages>/package and then symlinks from /usr/local/{bin,lib}
> > and removal of a package is just removing its one directory recursively
> > and cleaning up any orphaned links vs. files put directly into
> > /usr/local/{bin,lib} and data maintained on the side as to which file
> > came from which package.
> 
> Well, setting it to /usr/local/cm3 would eliminate name clashes, but it
> would also move cm3 out of the standard path.  That would require every
> user to adjust their path.
> 
> If were were talking about 1-3 symlinks in /usr/local/bin then that
> would be fine, but if it's like 25+ then that could be kind of pointless.
> 
> Plus on FreeBSD documentation, config, and examples go in standard
> locations (if possible) and setting to /usr/local/cm3 without
> modification wouldn't solve that.
> 
> We aren't worried about orphan files or whatever, the binary package
> manager cleans up after itself when a package is removed, and won't let
> two versions of a package be installed simultaneously, so there's no
> real benefit to having cm3 in a dedicated directory (IMO).
> 
> > Just because it is called "config", does not make it "config".
> > It should be refactored.
> > And will there be some expectation that the "binaries" can be
> > updated while leaving "config" alone?
> 
> No.  With updates, everything that was installed gets removed.  If this
> is part of an update, everything is reinstalled.  There's always
> integrity there.  For BSD setups, having it at etc/modula3/config makes
> a lot of sense and there's no downside other than it's a different
> location from releases that you guys may make.

It doesn't really fit, but never mind.
What is different about M3 is that it contains both the base development
system and dozens of utility and application packages, and every user
is supposed to be able to update and install packages (only it's
called shipping, not installation).

Theoretically, you could package each M3 package in its own BSD
package; I even think there was one (historical) distribution of PM3
that did exactly that. That doesn't address the problem, as each user
needs to become root to ship a package.

As I've written in another m3 thread yesterday, what would really
be needed is a multi-level package pool hierarchy and an integrated
m3 builder that copes with that and sets of packages. But even if we had
that, I'm not sure how it would fit into the standard Unix file system
hierarchy layout: put the user-managed package pools under /var/local/lib?

As the package systems vary significantly between all the supported
platforms of M3, the concepts of M3 packages and OS packages have
never been unified. And of course the M3 project never had enough
personal resources to provide OS specific packages for even a small
subset of the target platforms.

Perhaps a pragmatical way to handle this would be to package and
install a minimal system only containing the builder, compiler and
base libraries as an OS package in an OS-specific way (including
documentation and all) and add support for the standard M3 package
hierarchy under /usr/local/cm3 (group-writable by an m3 group).
It would be a compromise, but perhaps a better one than installing
the complete CM3 distribution as one big package read-only for
the ordinary user.

The CM3 package pool under /usr/local/cm3 could even be integrated
with the Github repository and allow easy checkout of all M3
packages there and even pushing new branches and packages. The
builder could locate, checkout and install missing imported packages,
have an option for creating a new package template and a standard
way to publish this on Gibhub. This might help to lower the threshold
for new users to become active in the community and share their
code.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194