Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 667334

Summary: dev-ml/opam-2.0.3 version bump
Product: Gentoo Linux Reporter: Anton Kochkov <anton.kochkov>
Component: Current packagesAssignee: Gentoo Team for the ML programming language family <ml>
Status: CONFIRMED ---    
Severity: normal CC: jstein
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Package list:
Runtime testing required: ---
Attachments: ebuild using opam-full archive
ebuild using opam-full archive (v2)

Description Anton Kochkov 2018-09-30 06:18:02 UTC
Now the Opam 2.0 released the whole OCaml infrastructure switching to the new version, so the opam repository:

What you need to be aware of

Some commands have changed syntax:

    opam switch: create must be specified to create a new switch. You should then specify either --empty or a base compiler package, e.g. use opam switch create 4.06 ocaml-base-compiler.4.06.0 to create a new switch named 4.06. Just opam switch create 4.06.0 also still works in most cases.

    opam repository (or opam remote): repositories are still configured globally, but are now selected for each switch. So by default opam repository add will only affect the current switch. You can change the defaults with --set-defaults, and choose the repositories at switch creation time with opam switch create --repositories REPOS

    opam list and opam show have been largely reworked to offer more options

    options to build tests and documentation are now respectively --with-test and --with-doc. They only apply to packages listed on the command-line

The opam-admin tool, for repository operations, is now built into opam, use the opam admin command instead.

Opam now comes with a solver built-in, which means that installing aspcud alongside opam is no longer required.

Pinning to a version-controlled directory will now only use what is committed by default (opam 1.2 had a "mixed mode" where it would use the current versions of files, but only the version-controlled ones. This was good most of the time, but could become puzzling e.g. when opam didn't see an added source file). The option --working-dir can be used to temporarily make opam fetch uncommitted changes (see also --inplace-build), and --assume-built to run only installation instructions, assuming that build has been done locally. Upon pinning, opam 2.0 will also select the current branch by default if unspecified, so that later running git checkout BRANCH in the source tree doesn't affect the pinned package.
New features

    new command aliases: opam var, opam exec, opam env can be used in place of the corresponding opam config subcommands

    new command: opam clean to clear caches, logs, etc.

    local switches: use e.g. opam switch create . to create a switch in the current directory. The switch contents will be in a _opam directory, which can be safely removed once done. The switch path can then be used as a handle to refer to the switch. Additionally, the above command will install any packages which definitions are found in the selected directory into the local switch.

    automatic pinning: use e.g. opam install . to pin and install any packages found in the current directory. opam install . --deps-only can also be used to prepare a switch for working with a source tree. This extension also concerns the remove, upgrade, reinstall and show commands, and specifying the path to a specific opam file is also supported.

    archive caching: opam now uses a much better caching mechanism, both locally and on the opam-repository. In particular, upstream repositories being down should no longer prevent package installation (even for older or removed packages). Git repositories are also cached.

    better error mitigation, messages and recovery. opam install --restore can be used to retry after a failed operation.

    a plugin, e.g. opam-depext, will now be available from all switches once installed in one.

    opam install --destdir can be used to copy build artefacts of given packages to an external prefix

    sandboxing: on Linux and MacOS, all package commands will now be sandboxed by default. The bubblewrap tool is now required to this end on Linux, and the sandbox_exec command is used on MacOS.
Comment 1 Christian D. 2018-10-05 11:40:21 UTC
The main problem is, that the OPAM developers chose to essentially freeze the repository for users of the 1.x version: 

Package maintainers should be aware of the following:
- the master branch of the opam package repository is now in the 2.0.0 format
- package submissions must accordingly be made in the 2.0.0 format, or using the new version of opam-publish (2.0.0)
- anything that was merged into the repository in 1.2 format has been automatically updated to the 2.0.0 format
- the 1.2 format repository has been forked to its own branch, and will only be updated for critical fixes.

I stumbled across this bug because one of the packages I use released an update which is only available to users of 2.0. 

While I think that this is a very poor decision on the part of the OPAM developers, this means that supporting version 2.0 is relatively urgent.
Comment 2 Alexis Ballier gentoo-dev 2018-10-05 16:12:40 UTC
Version 2.0 has been available for a while here:
Comment 3 Christian D. 2018-10-06 09:23:17 UTC
Thank you for the pointer (and your efforts). However, I still think it would be nice if one didn't have to install an overlay in order to install a package manager that provides just about everything in the overlay (and the ability to quickly switch between setups). Also, I don't see a reason to split opam into 10 different packages. 

Would you be willing to provide an ebuild for a single opam package for the main tree?
Comment 4 Anton Kochkov 2019-03-26 04:27:55 UTC

* Fix manpage remaining $ (OPAMBESTEFFORT)
* Fix OPAMROOTISOK handling
* Regenerate missing environment file

* Update build from jbuilder to dune
* Doc:
  * update man page
  * add message for deprecated options
  * reinsert removed ones
  * deprecate `no-aspcud`
* Pin:
  * upgrade pin depends on pinning
  * include descr & url files on pinning 1.2 opam files
* Sandbox:
  * handle symlinks in bwrap
  * allow use of internal sockets on
  * change one-line conditional to if statement which was incompatible with set -e
  * make /var readonly instead of empty and rw
* Path: resolve default opam root path
* System: suffix .out for read_command_output stdout files (#3644)
* Locked: check consistency with opam file when reading lock file to suggest regeneration message
* Show: remove pin depends messages
* Cudf: Fix closure computation in the presence of cycles
* List: Fix some cases of listing coinstallable packages
* Format upgrade: extract archived source files of version-pinned packages
* Core: add is_archive in OpamSystem and OpamFilename
* Init: don't fail if empty compiler given
* Lint: fix light_uninstall flag for error 52
* Update cold compiler to 4.07.1

* Cold boot for MacOS/CentOS/Alpine
* Install checksum validation on MacOS
* Archive extraction for OpenBSD now defaults to using gtar
* Fix compilation of mccs on MacOS and Nix platforms
* Do not use GNU-sed specific features in the release Makefile, to fix build on OpenBSD/FreeBSD
* Cleaning to enable reproducible builds
* Update configure scripts
* git: fix git fetch by sha1 for git < 2.14
* linting: add test variable warning and empty description error
* upgrade: convert pinned but not installed opam files
* error reporting: more comprehensible error message for tar extraction, and upgrade of git-url compilers
* opam show: upgrade given local files
* list: as opam 2.0.0 list doesn't return non-zero code if list is empty, add --silent option for a silent output and returns 1 if list is empty
Comment 5 Christian D. 2019-05-19 14:02:56 UTC
Created attachment 577312 [details]
ebuild using opam-full archive

I wrote an ebuild building opam from the "opam-full" archive including most of the dependencies of opam. The rationale for this is that

1. Some of the dependencies of opam are not in the main portage tree

2. Most users of opam will install the OCaml packages they use via opam, so there is really no need to pull in all sorts of ocaml packages into the system if they are not used to build other system packages.

Ebuild works for me, but is largely untested.
Comment 6 Benda Xu gentoo-dev 2019-05-22 13:24:29 UTC
Comment on attachment 577312 [details]
ebuild using opam-full archive

Hi Christian,

Thank you for your ebuild! Please run `repoman full` to check your ebuild.

I have spotted some points to improve your ebuild, as shown below.

># Copyright 1999-2017 Gentoo Foundation
># Distributed under the terms of the GNU General Public License v2

Please use EAPI 7.

>inherit eutils

Why is this needed?

>DESCRIPTION="A source-based package manager for OCaml"
>KEYWORDS="~amd64 ~arm ~arm64 ~ppc ~x86"

>if [[ ${PV} != 9999 ]]; then
>      	SRC_URI="${PN}/releases/download/${PV}/${PN}-full-${PV}.tar.gz"
>	inherit git-r3
>src_configure() {
>	econf --prefix="/usr" --with-mccs

--prefix="${EPREFIX}/usr", so that it will work on Prefix.

>	make lib-ext
>src_compile() {
>	#passing -jX to the dune build leads to errors

Please submit a bug for this upstream and put a link here.

>	make


If you intend to call make, be sure it is guarded with `|| die`:  make || die.

>src_install() {
>        emake DESTDIR="${D}" install

Use the phase `default` for conciseness.

See for example,

>	#remove spurious opam-installer files
>	#see:
>	rm -r "${D}usr/doc/opam-installer" "${D}usr/lib/opam-installer"
>	rmdir "${D}usr/doc" "${D}usr/lib"

Any external command should be guarded with `|| die`.

See the above src_compile()


Comment 7 Christian D. 2019-05-22 20:33:09 UTC
Created attachment 577610 [details]
ebuild using opam-full archive (v2)

Thank you for your feedback, the ebuilds I have written so far were mostly for personal use. 

I removed the "test" USE-flag (got weird errors) and the git build (requires more dependencies). 

Thinking about it, it might be better to name this package "opam-full" and provide a regular "opam" package eventually, once all the dependencies of the regular opam build have trickled into the main repository. I'll leave that up to you maintainers.
Comment 8 xsnaut 2019-07-21 17:14:41 UTC
Is there anything preventing the merge? I tested the attached ebuild and it worked for me.
P.S. More and more repos migrate to the new format, rendering opam 1.3 unusable.