[erlang-questions] Erlang package manager
Tue Dec 16 18:05:15 CET 2014
in addition to what others have said, here's a list of other important
-- must haves --
* archival of published versions
* real version constraint solver (SAT)
* instead of blindly following semver, look at RPM versioning. see
comments starting here:
* 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
- 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
* 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
* 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.
More information about the erlang-questions