[erlang-questions] Erlang package manager

[Tuncer Ayaz]

Hi Bruce,

in addition to what others have said, here's a list of other important
features.

-- must haves --
* archival of published versions

* real version constraint solver (SAT)

* instead of blindly following semver, look at RPM versioning. see
  comments starting here:
  https://github.com/rebar/rebar/issues/240#issuecomment-38035168

* design index _and_ packages folder with mirroring in mind:
  - avoid SPOF (availability and reliability issues)
  - allow local mirrors
  - Ideally avoid the use of a CDN and use mirrors like FreeBSD, CTAN,
    and Linux distros do. This means, master is only written to when
    the index is updated and normally no client operation should
    contact master. So, only mirrors should ever be in contac with
    the master.
  - Avoiding a CDN solves multiple issues:
    + no superfluous hosting costs due to unnecessary centralization.
      hosting costs may not be a problem today, but a package index
      and repo of open source code does not need to be hosted in a
      central location by one administrating org.
    + No accessibility issues for geographical or organizational
      network reasons. This is where the ability to mirror, as in CTAN
      or Debian mirror, is a vital feature.
    + No downtime if, say, S3 is for some reason inaccessible or its
      availability is limited.
  - With a proper mirroring system in place, the only operation that can
    suffer is modification of the index+package_dir. That means, no r/o
    user will be affected if EIUG takes master down for maintenance.
    This may seem like it's not a problem, but compared to centralized
    solutions, I never once had a remote reliability problem when
    operating on Linux, BSD, or CTAN packages.
  - Based on the multitude of mirrors for BSD, Linux, CTAN, etc., I
    believe it's more likely for someone to host another mirror than
    expecting such offers to turn into monetary support for covering
    costs of a centralized system.


-- nice to have --
* pinning as - in stay at this version and do not down-/up-grade

* pinning local package as in 'opam source PKGNAME --pin'

* regardless of .ez limitations, architecture specific variants of a
  package

* delta index (Debian-like) and package updates (Fedora-like)


-- to be careful about --
* generating native packages (FreeBSD pkg, dpkg, rpm, etc.) is nice to
  have, but if existing issues of, say, the way Perl is packaged in
  Linux distros is any indication, I'd say it should only be optional.

* a git repository with its history is not a suitable mechanism to
  store either the index or the packages

-- extra notes --
I had planned to work on .ez-fying all libs/apps in
OTP-18.0, but I haven't had the time to approach that yet. I mention
that because we definitely have to improve support in that space
first, especially:

* Make sure everything works with .ez archives without first
  extracting (like JAR and WAR archives).

* Figure out official extensions of .app fields to properly support
  packaging in general.

* Figure out a convention to load .so/.dll from .ez and extend the
  loaders accordingly. It's up for discussion whether somepkg-1.0.ez
  should bundle all .so/.dll files or if there should be one
  somepkg-1.0-<ARCH>.ez for each supported architecture.