[opam-devel] How to manage a package manager (Was: Re: [opam] Build clarification (#1149))
fabien.dagnat at telecom-bretagne.eu
Sat Feb 1 22:19:27 GMT 2014
Le 1 févr. 2014 à 15:30, Anil Madhavapeddy <anil at recoil.org> a écrit :
> My point is that the user originally obtains their version of OPAM via their
> OS package manager (Homebrew, apt, BSD ports, Yum, etc). All of these managers
> provide a mechanism to warn the user of any upgrade steps that need to happen
> when upgrading their distribution, and so is an ideal way to update OPAM
> itself in the event of incompatible future changes.
> In contrast, `opam update` is part of a *development* workflow, not a system
> upgrade path. I do that when I want to recompile some part of my working
> trees to a new package set, and often follow it up with an upgrade (via -u).
Sorry, but I disagree here. I'm a regular user of tlmgr the package manager of tex-live and I appreciate the fact that it informs me of upgrade of itself and allows me to upgrade itself. (I'm not plainly satisfied that it forces me to do so...)
We are, more and more, evolving in a jungle of package managers (all using specific workflows for good reasons), I dream that one day, we will be able to simplify this landscape...
Personally, I use the os x system for updates + homebrew + tlmgr + opam + cabal + cpan + rubyGems + easy_install or pip + firefox update system + emacs package system + eclipse + maven... Hard to even build the list of all the package manager one's use...
Maître de conférences au département informatique
Responsable de la filière Systèmes Logiciels et Réseaux
Tél. : (0 | 33) 2 29 00 14 09 Technopôle Brest-Iroise, CS 83818
29238 Brest Cedex 3, France
Une école de l'Institut Mines-Télécom
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the opam-devel