[M3devel] It works!

[Jay]

I am sympathetic to "path pollution" concerns even if in usr/local/cm3. We can move some stuff to demobin or samplebin if agreement on uselessness. And/or prefix every bin & lib with m3 or cm3. We should also rev our so versions? & and install version-named cm3 & cm3cg?

 - Jay

On Jun 3, 2015, at 4:46 AM, John Marino <adacore at marino.st> wrote:

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