Closed edwintorok closed 10 years ago
Here is the cudf file created by 'opam install --cudf=foo cstruct.1.3.1': https://gist.githubusercontent.com/edwintorok/7b1e8997461dcdff72d7/raw/c406c311410217eef34d6144de675a3361ec8971/gistfile1.txt
[if you are looking for a quick solution, just skip to the end of the message :-)]
Thanks for providing the cudf file: it made it easy to spot the issue here, which is in the preference expression used as default in older versions of opam, "-removed,-notuptodate,-new"; you can see it looking at the first line of the cudf file:
With this preference expression, downgrades may slip in: indeed, we are asking the solver to minimise package removal, then maximise packages that are at their latest version, and then minimise packages that were not there before. If one package cannot be installed at the latest version, and is not new, then nothing is specified, and the solver may very well provide a solution with a downgrade.
The current version of opam in trunk has a different default value, which is -removed,-notuptodate,-changed ^^^^^^^^ which, on your particular case, provides a satisfactory solution preventing the downgrade.
Actually, the best preference expression for installations should be something like
-count(removed),-notuptodate(request),-count(down),-count(changed)
but this extended preference language requires to have aspcud 1.9 or lated installed, or to use the solver farm at cudf-solvers.irill.org and since this is not the case for everybody out there (yet), we could not put this in the code as a default.
If you do not want/need to upgrade to a more recent opam, just run opam with the --criteria option, as in
opam install ... --criteria="-removed,-notuptodate,-changed"
And if you have aspcud 1.9 or later installed, use the more refined preference expression below
-count(removed),-notuptodate(request),-count(down),-count(changed)
For more info on the preference language and its use, see
http://www.slideshare.net/robertodicosmo3/leveraging-solver-preferences-to-tame-your-package-manager http://www.dicosmo.org/Articles/usercriteria.pdf
On Sun, Jul 13, 2014 at 01:16:52AM -0700, Török Edwin wrote:
Here is the cudf file created by 'opam install --cudf=foo cstruct.1.3.1': https://gist.githubusercontent.com/edwintorok/7b1e8997461dcdff72d7/raw/ c406c311410217eef34d6144de675a3361ec8971/gistfile1.txt
— Reply to this email directly or view it on GitHub.*
Roberto Di Cosmo
Professeur En delegation a l'INRIA
PPS E-mail: roberto@dicosmo.org
Universite Paris Diderot WWW : http://www.dicosmo.org
Case 7014 Tel : ++33-(0)1-57 27 92 20
5, Rue Thomas Mann
F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo
Attachments: MIME accepted, Word deprecated
Office location:
Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
Thanks. There is no --criteria
flag in opam 1.1.1, but I set $OPAMCRITERIA in .bashrc:
export OPAMCRITERIA='-count(removed),-notuptodate(request),-count(down),-count(changed)'
Apparently I needed to escape the paranthesis:
$ echo $OPAMCRITERIA -count\(removed\),-notuptodate\(request\),-count\(down\),-count\(changed\)
Indeed, the environment variable is a way to go for old opam.
Notice though that this will set the preferences for all opam commands, including upgrades, but for upgrades you really want another criterion
-count(down),-count(removed),-notuptodate(solution),-count(new)
In opam 1.2 you have two different environment variables, OPAMCRITERIA and OPAMUPGRADECRITERIA
Roberto
On Sun, Jul 13, 2014 at 03:10:36AM -0700, Török Edwin wrote:
Thanks. There is no --criteria flag in opam 1.1.1, but I set $OPAMCRITERIA in .bashrc: export OPAMCRITERIA='-count(removed),-notuptodate(request),-count(down),-count (changed)'
Apparently I needed to escape the paranthesis:
$ echo $OPAMCRITERIA -count(removed),-notuptodate(request),-count(down),-count(changed)
— Reply to this email directly or view it on GitHub.*
Thanks, I added some aliases to my bashrc for now:
alias opaminstall="OPAMCRITERIA='-count\(removed\),-notuptodate\(request\),-count\(down\),-count\(changed\)' opam install" alias opamupgrade="OPAMCRITERIA='-count\(down\),-count\(removed\),-notuptodate\(solution\),-count\(new\)' opam upgrade"
You are welcome! This should be much simpler in opam 1.2, and I'm really looking forward to having recent external solvers becoming the standard, so the default values for the preferences will be able to go into the real code.
On Sun, Jul 13, 2014 at 04:55:26AM -0700, Török Edwin wrote:
Thanks, I added some aliases to my bashrc for now:
alias opaminstall="OPAMCRITERIA='-count(removed),-notuptodate(request),-count(down),-count(changed)' opam install" alias opamupgrade="OPAMCRITERIA='-count(down),-count(removed),-notuptodate(solution),-count(new)' opam upgrade"
— Reply to this email directly or view it on GitHub.*
Roberto
Is it reasonable to do version detection on aspcud in opam 1.2 so that if a recent external solver is present, opam 1.2 users will get good solution criteria without effort? This might be helpful in 9 months when most users are on opam 1.2 and aspcud 1.9+ is more widespread...
It would be surely a plus to be able to support different versions of the request language, and different external solvers (that may have slightly different command line interfaces): for example, packup is invoked with a few extra options w.r.t. apscud.
But this means adding an extra layer of complexity to the opam code: in particular, in solver/opamCudf.ml one should not rely, as today, on a single "external_solver_command", but use a structure detailing the different solvers known, the values of their default preferences, the method to detect them, etc.
If somebody volunteers to do this, I'll be happy to provide support with knowledge on the solvers...
Roberto Le 13 juil. 2014 16:03, "David Sheets" notifications@github.com a écrit :
Is it reasonable to do version detection on aspcud in opam 1.2 so that if a recent external solver is present, opam 1.2 users will get good solution criteria without effort? This might be helpful in 9 months when most users are on opam 1.2 and aspcud 1.9+ is more widespread...
— Reply to this email directly or view it on GitHub https://github.com/ocaml/opam/issues/1516#issuecomment-48841347.
I've opened #1518 to track this. I may take a look at implementing this next weekend. Thanks for your support, Roberto!
You are welcome, I'll add some info on #1518
On Sun, Jul 13, 2014 at 08:28:33AM -0700, David Sheets wrote:
I've opened #1518 to track this. I may take a look at implementing this next weekend. Thanks for your support, Roberto!
— Reply to this email directly or view it on GitHub.*
Roberto Di Cosmo
Professeur En delegation a l'INRIA
PPS E-mail: roberto@dicosmo.org
Universite Paris Diderot WWW : http://www.dicosmo.org
Case 7014 Tel : ++33-(0)1-57 27 92 20
5, Rue Thomas Mann
F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo
Attachments: MIME accepted, Word deprecated
Office location:
Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
Trying to upgrade cstruct would cause a downgrade of tyxml (why?):
Trying to explicitly install both cstruct and tyxml:
Trying all 3 now:
Using the built-in solver instead of aspcud works too (but of course its much slower):
Here is the debug output with default solver (aspcud):
With built-in solver: