[M3devel] It works!

[John Marino]

On 6/3/2015 13:11, Olaf Wagner wrote:
> 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).

If I just install the "all" distribution, as built, in /usr/local/cm3
(with the possible exception of shifting www to standard docs location):

1) It is a read-only area (ideally)
2) It would require all users to set /usr/local/cm3 in PATH.

This is not really that big of a deal.  It's not the first package to
require something like that, plus, frankly, the m3 community is not
large and such a requirement could be imposed without a lot of backlash.

Maybe this is the best solution after all (and again it makes the port
makefile simpler)


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

Breaking each into it's own package is what should happen, but that
requires work on my part that I'm not able to give, so everyone has to
deal with the giant port.  If m3 regains enough popularity to justify
splitting into individual packages then we can revisit the decision.

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

At least for ports, packages either go in root's areas (e.g. /usr/local)
or user-accessible areas but not mixed.  One can install M3 in a user's
area and do what they want.  But a generic user can't install to
standard areas like /usr/local and most /var areas.


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

Pragmatically, you want the individual platforms to package it for you.
 Less work for you and it's probably done more correctly.  E.g. m3 is
self-hosting on FreeBSD so there's no real need to provide FreeBSD
support now (with the possible exception of a statically linked "min"
distribution)

Ideally, similar support occurs on Debian, Fedora, Arch, macports, etc.

John