Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

+ ocaml-mysql 1.2.2 #10312

Merged
merged 2 commits into from
Sep 26, 2017
Merged

+ ocaml-mysql 1.2.2 #10312

merged 2 commits into from
Sep 26, 2017

Conversation

ygrek
Copy link
Contributor

@ygrek ygrek commented Sep 20, 2017

No description provided.

@camelus
Copy link
Contributor

camelus commented Sep 20, 2017

✅ All lint checks passed 360238a
  • These packages passed lint tests: conf-mariadb.1, mysql.1.2.2

✅ Installability check (7463 → 7465)
  • new installable packages (2): conf-mariadb.1 mysql.1.2.2

@ygrek
Copy link
Contributor Author

ygrek commented Sep 21, 2017

I guess build fails due to libmysqlclient-dev not present on current debian. Should use libmariadbclient-dev instead. The question is how to update conf-mysql - upgrade version or create alternative conf-mariadb package?

@samoht
Copy link
Member

samoht commented Sep 21, 2017

I guess build fails due to libmysqlclient-dev not present on current debian. Should use libmariadbclient-dev instead. The question is how to update conf-mysql - upgrade version or create alternative conf-mariadb package?

Did that changed on every version of Debian?

@ygrek
Copy link
Contributor Author

ygrek commented Sep 22, 2017

No, only in stretch (current stable). Previous stable (jessie) is using libmysqlclient-dev. ocaml-mysql will work with both (and I hate to have package uninstallable because of conf-* not up-to-date, in my opinion it should not be a fatal error, but a warning, or opam should have --force option to allow install anyway if deps fail).

@ygrek
Copy link
Contributor Author

ygrek commented Sep 22, 2017

I have created conf-mariadb and made it alternative dependency for ocaml-mysql

@ygrek
Copy link
Contributor Author

ygrek commented Sep 22, 2017

apparently conf-mariadb in homebrew doesn't provide mysql_config unlike all other mariadb development packages..

@samoht
Copy link
Member

samoht commented Sep 22, 2017

yes I saw that. Not necessary a blocking issue for merge ... but I am more concerned with Datakit CI which seems down...

@ygrek
Copy link
Contributor Author

ygrek commented Sep 23, 2017

Please let me know if I need to do anything to get this merged

@ygrek
Copy link
Contributor Author

ygrek commented Sep 25, 2017

apt-get install -qq -yy libmariadbclient-dev libmysqlclient-dev

depext decides to install both.. (and fails). Looks like it doesn't like alternatives much

@samoht
Copy link
Member

samoht commented Sep 26, 2017

@avsm @AltGr a good example on why we need better depexts.

I think I am ok to merge the package, although the situation is clearly not perfect. @ygrek as maintainer of the package, I will let you decide if having depext at all is a good idea in the present situation or not.

@samoht samoht merged commit e50b068 into ocaml:master Sep 26, 2017
@ygrek
Copy link
Contributor Author

ygrek commented Sep 26, 2017

I think I will remove dependency on conf-* and add install-fail message explaining situation until alternative depexts will be working

@AltGr
Copy link
Member

AltGr commented Sep 27, 2017

Once I get the detailed OS variables (please check and report, I have had no feedback yet, which also means it remains low priority) sorted out, and the improved depexts: expressivity, you should be able to write something like:

depexts: [
  "libmariadbclient-dev" { distribution = "debian" & dist-version >= "9" | distribution = "ubuntu" & ... }
  "libmysqlclient-dev" { distribution = "debian" & dist-version < "9" | ... }
  ...
]

This means not using the conf packages though (or a specific mariadb-or-mysql one). Being able to use depends: [ "conf-mysql" | "conf-mariadb" ] would be much more difficult, and require an advanced version of the planned depexts design : opam would need to check the depexts of all packages in advance, triaging through the host package manager the installed, available but not installed, and unavailable ones, then call its solver with the packages with unavailable depexts removed, and call the host package manager again after getting its solution to install any remaining required uninstalled system packages.

This way, only the conf-*db package that is compatible with the system would be seen as available by opam's solver, and the right branch of the disjunction would get chosen: there is no way to do this without a preliminary query to the host PM.

All the difficulty, apart from having good depexts specification on the repo, remains in having reliable and fast interaction with the host PM, on all platforms. opam-depext is still much simpler than that.

@ygrek
Copy link
Contributor Author

ygrek commented Sep 27, 2017

I still feel this (describing system and system packages in opam files) goes in wrong direction (too many moving things). I don't have any constructive ideas how to solve the original problem. Maybe it is fine to aim for 95% working and fail in remaining exotic system setups. To me it seems that showing suggested depexts (it is already case iirc) and allowing to force install of packages (e.g. when conf-* package is wrong and user wants to compile binding anyway) would go long way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants