search

ocaml / opam

opam is a source-based package manager. It supports multiple simultaneous compiler installations, flexible package constraints, and a Git-friendly development workflow.
https://opam.ocaml.org
Other
1.25k stars 362 forks source link

Wrong dependency resolution #1310

Closed Drup closed 9 years ago

Drup commented 10 years ago

I'm not completly sure it's opam or aspcud related, but I found a bug in the dependency resolution algorithm. In a fresh new switch (here, it's an alias of 3.12.1), and with the opamocsigen repository, I did install opam eliom and got the following install : 

The following actions will be performed:
 - install   ocamlfind.1.4.0                       [required by eliom]
 - install   conf-libpcre.1                        [required by pcre-ocaml]
 - install   type_conv.109.60.01                   [required by deriving]
 - install   ssl.0.4.6                             [required by ocsigenserver]
 - install   react.1.0.0                           [required by ocsigenserver]
 - install   ounit.2.0.0                           [required by fileutils]
 - install   optcomp.1.5                           [required by deriving]
 - install   ocamlify.0.0.1                        [required by oasis]
 - install   menhir.20130912                       [required by js_of_ocaml]
 - install   ipaddr.2.4.0                          [required by ocsigenserver]
 - install   dbm.1.0                               [required by ocsigenserver]
 - install   cryptokit.1.9                         [required by ocsigenserver]
 - install   calendar.2.03.2                       [required by eliom]
 - install   pcre-ocaml.7.0.4                      [required by ocsigenserver]
 - install   ocaml-data-notation.0.0.11            [required by oasis]
 - install   lwt.2.4.4                             [required by ocsigenserver, js_of_ocaml]
 - install   fileutils.0.4.4                       [required by ocamlmod]
 - install   ocamlnet.3.7.3                        [required by ocsigenserver]
 - install   ocamlmod.0.0.4                        [required by oasis]
 - install   oasis.0.4.4                           [required by deriving]
 - install   tyxml.9999                            [required by ocsigenserver]
 - install   deriving.9999                         [required by eliom]
 - install   ocsigenserver.9999                    [required by eliom]
 - install   js_of_ocaml.9999                      [required by eliom]
 - install   eliom.9999

however, here is the opam info for lwt.2.4.4 : 

opam info lwt.2.4.4
             package: lwt       
             version: 2.4.4
          repository: default
        upstream-url: https://github.com/ocsigen/lwt/archive/2.4.4.tar.gz
       upstream-kind: http
   upstream-checksum: 7f3e8d63055763004bb49ff4e7db44ea
             depends: ocamlfind
             depopts: base-threads | base-unix | conf-libev | ssl | react < 1.0.0 | lablgtk | ocaml-text
  installed-versions: lwt.2.4.3 [4.01.0+fp], lwt.2.4.4 [eliom_vanilla 4.01.0 3.12.1]
  available-versions: 2.3.2, 2.4.0, 2.4.1, 2.4.2
         description: A cooperative threads library for OCaml

Predictably, lwt's compilation failed. When I did opam install lwt after the failure, react was downgraded correctly.

You can find the cudf call here : http://pastebin.archlinux.fr/499428 opam git-version is 9a822dafdf2942be89e3bf6dc6fe6a66728999b5 aspcud is version 1.9.1, commit r8373

rdicosmo commented 10 years ago

Thanks for reporting... unfortunately, http://pastebin.archlinux.fr/499428 is truncated (maybe pastebin is limited to 64Kb?)... may you try using a gist instead?

On Sat, Apr 05, 2014 at 05:43:18AM -0700, Drup wrote:

I'm not completly sure it's opam or aspcud related, but I found a bug in the dependency resolution algorithm. In a fresh new switch (here, it's an alias of 3.12.1), and with the opamocsigen repository, I did install opam eliom and got the following install :

The following actions will be performed:

  • install ocamlfind.1.4.0 [required by eliom]
  • install conf-libpcre.1 [required by pcre-ocaml]
  • install type_conv.109.60.01 [required by deriving]
  • install ssl.0.4.6 [required by ocsigenserver]
  • install react.1.0.0 [required by ocsigenserver]
  • install ounit.2.0.0 [required by fileutils]
  • install optcomp.1.5 [required by deriving]
  • install ocamlify.0.0.1 [required by oasis]
  • install menhir.20130912 [required by js_of_ocaml]
  • install ipaddr.2.4.0 [required by ocsigenserver]
  • install dbm.1.0 [required by ocsigenserver]
  • install cryptokit.1.9 [required by ocsigenserver]
  • install calendar.2.03.2 [required by eliom]
  • install pcre-ocaml.7.0.4 [required by ocsigenserver]
  • install ocaml-data-notation.0.0.11 [required by oasis]
  • install lwt.2.4.4 [required by ocsigenserver, js_of_ocaml]
  • install fileutils.0.4.4 [required by ocamlmod]
  • install ocamlnet.3.7.3 [required by ocsigenserver]
  • install ocamlmod.0.0.4 [required by oasis]
  • install oasis.0.4.4 [required by deriving]
  • install tyxml.9999 [required by ocsigenserver]
  • install deriving.9999 [required by eliom]
  • install ocsigenserver.9999 [required by eliom]
  • install js_of_ocaml.9999 [required by eliom]
  • install eliom.9999

however, here is the opam info for lwt.2.4.4 :

opam info lwt.2.4.4 package: lwt version: 2.4.4 repository: default upstream-url: https://github.com/ocsigen/lwt/archive/2.4.4.tar.gz upstream-kind: http upstream-checksum: 7f3e8d63055763004bb49ff4e7db44ea depends: ocamlfind depopts: base-threads | base-unix | conf-libev | ssl | react < 1.0.0 | lablgtk | ocaml-text installed-versions: lwt.2.4.3 [4.01.0+fp], lwt.2.4.4 [eliom_vanilla 4.01.0 3.12.1] available-versions: 2.3.2, 2.4.0, 2.4.1, 2.4.2 description: A cooperative threads library for OCaml

Predictably, lwt's compilation failed. When I did opam install lwt after the failure, react was downgraded correctly.

You can find the cudf call here : http://pastebin.archlinux.fr/499428 opam git-version is 9a822da aspcud is version 1.9.1, commit r8373

— 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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

Drup commented 10 years ago

Here ! https://gist.github.com/9991834

rdicosmo commented 10 years ago

Thanks, this time it's complete!

Looking at it

On Sat, Apr 05, 2014 at 06:21:45AM -0700, Drup wrote:

Here ! https://gist.github.com/9991834

— Reply to this email directly or view it on GitHub.*

rdicosmo commented 10 years ago

Ok, looked at this through the cudf dump you provided; the metadata for lwt 2.4.4, which is the following

         package: lwt
         version: 2.4.4
      repository: default
    upstream-url: https://github.com/ocsigen/lwt/archive/2.4.4.tar.gz
   upstream-kind: http

upstream-checksum: 7f3e8d63055763004bb49ff4e7db44ea depends: ocamlfind depopts: base-threads | base-unix | conf-libev | ssl | react < 1.0.0 | lablgtk | ocaml-text installed-versions: lwt.2.4.3 [4.01.0+fp], lwt.2.4.4 [eliom_vanilla 4.01.0 3.12.1] available-versions: 2.3.2, 2.4.0, 2.4.1, 2.4.2 description: A cooperative threads library for OCaml

gets converted into the CUDF file as

package: lwt version: 6 depends: base-threads , base-unix , ocamlfind conflicts: lwt opam-name: lwt opam-version: 2.4.4

Indeed base-threads, base-unix and ocamlfind are the only packages already installed (you are on a new switch, which has exactly those ones), and depopts are converted into hard dependencies for installed packages.

So the solver, that only sees the CUDF file, has no knowledge that lwt 2.4.4 is incompatible with react >= 1.0.0, and proposes a solution that installs react=1.0.0 and you get an error.

One could wonder what the precise semantics of depopts is, but my position here is that when a given package is incompatible with another one, this must be translated into a conflict, and one should see a

conflicts : react >= 1.0.0

in the lwt metadata.

I am filing an issue on opam-repository, hope it will be fixed soon.

Roberto

On Sat, Apr 05, 2014 at 05:43:18AM -0700, Drup wrote:

I'm not completly sure it's opam or aspcud related, but I found a bug in the dependency resolution algorithm. In a fresh new switch (here, it's an alias of 3.12.1), and with the opamocsigen repository, I did install opam eliom and got the following install :

The following actions will be performed:

  • install ocamlfind.1.4.0 [required by eliom]
  • install conf-libpcre.1 [required by pcre-ocaml]
  • install type_conv.109.60.01 [required by deriving]
  • install ssl.0.4.6 [required by ocsigenserver]
  • install react.1.0.0 [required by ocsigenserver]
  • install ounit.2.0.0 [required by fileutils]
  • install optcomp.1.5 [required by deriving]
  • install ocamlify.0.0.1 [required by oasis]
  • install menhir.20130912 [required by js_of_ocaml]
  • install ipaddr.2.4.0 [required by ocsigenserver]
  • install dbm.1.0 [required by ocsigenserver]
  • install cryptokit.1.9 [required by ocsigenserver]
  • install calendar.2.03.2 [required by eliom]
  • install pcre-ocaml.7.0.4 [required by ocsigenserver]
  • install ocaml-data-notation.0.0.11 [required by oasis]
  • install lwt.2.4.4 [required by ocsigenserver, js_of_ocaml]
  • install fileutils.0.4.4 [required by ocamlmod]
  • install ocamlnet.3.7.3 [required by ocsigenserver]
  • install ocamlmod.0.0.4 [required by oasis]
  • install oasis.0.4.4 [required by deriving]
  • install tyxml.9999 [required by ocsigenserver]
  • install deriving.9999 [required by eliom]
  • install ocsigenserver.9999 [required by eliom]
  • install js_of_ocaml.9999 [required by eliom]
  • install eliom.9999

however, here is the opam info for lwt.2.4.4 :

opam info lwt.2.4.4 package: lwt version: 2.4.4 repository: default upstream-url: https://github.com/ocsigen/lwt/archive/2.4.4.tar.gz upstream-kind: http upstream-checksum: 7f3e8d63055763004bb49ff4e7db44ea depends: ocamlfind depopts: base-threads | base-unix | conf-libev | ssl | react < 1.0.0 | lablgtk | ocaml-text installed-versions: lwt.2.4.3 [4.01.0+fp], lwt.2.4.4 [eliom_vanilla 4.01.0 3.12.1] available-versions: 2.3.2, 2.4.0, 2.4.1, 2.4.2 description: A cooperative threads library for OCaml

Predictably, lwt's compilation failed. When I did opam install lwt after the failure, react was downgraded correctly.

You can find the cudf call here : http://pastebin.archlinux.fr/499428 opam git-version is 9a822da aspcud is version 1.9.1, commit r8373

— Reply to this email directly or view it on GitHub.*

Drup commented 10 years ago

The semantics that deopts with a version constraint don't imply conflict is not very intuitive. I would expect opam to be able to derive this constraint by himself.

rdicosmo commented 10 years ago

Unfortunately, the semantics of depopts is not really formalised, unlike depends and conflicts...

On Sat, Apr 05, 2014 at 06:55:41AM -0700, Drup wrote:

The semantics that deopts with a version constraint don't imply conflict is not very intuitive. I would expect opam to be able to derive this constraint by himself.

— 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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

AltGr commented 10 years ago

Actually, it should create a conflict. See tracker about depopts semantics, that indeed need to be formalised when combined with version constraints: #1131 I was surprised at first, but the current behaviour is supposed to be what Drup expected.

It would be clearer and more solid if we internally added a clear rule:

depopts: x {v}           => conflicts: x {not v}

Otherwise, this confirms my uncomfortable feeling about version constraints in depopts, which only really make sense with raw names at the moment (they are included, or restricted to the installed packages, depending on the action).

I think the rule above is the right fix and makes things clear: that would make it easy to fix.

Thanks @drup for finding this case !

AltGr commented 10 years ago

PR #1319 implements the above. There are still a few quirks though:

rdicosmo commented 10 years ago

Thanks! Some comments in the text

On Wed, Apr 09, 2014 at 01:03:30AM -0700, Louis Gesbert wrote:

PR #1319 implements the above. There are still a few quirks though:

• I also removed the hack creating a hard dependency depending on the installed state of package before install, because it helps a bit but doesn't guarantee a sound answer from the solver, as this bug shows.

Just for the record, there are two issues into play here:

1 according to the discussion in #200 a depopts: lwt & ssl like is found in cohttp was handled in the old code with the following logic: "if lwt or ssl are already installed, then add a hard dependency on both of them", but was simply ignored if neither lwt nor ssl were already installed.

As a consequence, if one then installs lwt by hand, there is no guarantee that ssl will also be installed, and when recompiling cohttp one gets an error.

2 since nothing else was done about depopts, no conflicts was generated to prevent installation of versions of packages incompatible with the one declared in the optional dependencies, and it was hence quite possible to get solutions from the solver that would break compilation by bringing in incompatible versions (as the one reported in this bug)

Your patch fixes (2), and disables the incomplete hack for (1)

However...

• Some packages use conjunctions of depopts (see #200 for the story). Their semantics aren't well defined, but as I understand it, they mean "I am in conflict with any subset of these packages that don't verify the whole conjunction". @avsm, can you confirm this is what you'd expect ? The thing is, in that case, I don't think it can be expressed to the solver, so we'll need to either find a way or be more restrictive.

What @avsm wants is the possibility to say that "for installing package A, none of these other 4 packages are necessary, but if one of them happens to become installed for other reasons, then all of them should be installed".

Since the dependency language used in CUDF can encode any boolean formula, in theory one can very well try to encode this requirement. In practice, though, things are more hairy: the speed in the resolution of dependencies by CUDF solvers comes in part from the fact that there are few conflicts around, and dependencies are forced to be in CNF because then one can directly encode them in the shape of a dual-horn formula, for which satisfiability is linear-time. Force-feeding arbitrary boolean formulae into CUDF can blow-up exponentially the size of the CUDF document and/or the solver resolution time.

For this reason, adding arbitrary logic connectors in the middle of dependencies is a bad thing, and should be avoided as much as possible.

The hack used by @samoht in #200 was a compromise to avoid these complex encodings but it does not provide a full solution, as explained above.

We need to find yet another way to handle this ...

• My current patch treats these conjunctions the same way as disjunctions, eg. depopt (a < 3 & b >= 2) will make the package conflct with a >= 3 and b < 2. This is sound, if not complete.

good!

• The installed-hack could be reintroduced with the added conficts patch, but I'd better wait until we find a real solution.

— 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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

samoht commented 10 years ago

Thanks for looking at this!

The original idea of depopts was the following:

  1. you want a way to express configuration-time state variables (such as if two packages are installed then enable a configure flag) which are computed when a new package is installed
  2. you want a way to detect these configuration-time constraints to recompile the package when needed

As it stands, OPAM uses the so-called filters to express 1. See for instance the %{foo:enable}% https://github.com/ocaml/opam-repository/blob/master/packages/lwt/lwt.2.4.4/opam#L4 which can also be combined: %{foo+bar:enable}}% is "enable" is both %{foo:enable}% and %{are:enable}% are (otherwise it's "disable").

To recompile such packages when a configuration-time variable change, OPAM uses the depopts field. The language here is a bit more involved, as it can be a full formula with version constraints. So it's a over-approximation of the real set.

As a consequence, if one then installs lwt by hand, there is no guarantee that ssl will also be installed, and when recompiling cohttp one gets an error.

not really, the configure step of cohttp checks that both packages are installed (if not, the errors is here).

So after some though, I don't think that we need to encode more stuff in constraints (which are not very expressive anyhow), but we should improve the language to express configuration-time variable, and check that we recompile these packages correctly when they change.

Does it make sense ?

samoht commented 10 years ago

So to come back to this issue, what I'm saying is that we should have a way to express something like:

  ["./configure" "--%{conf-libev:enable}%-libev" "--%{reac<=1.0.0:enable}%-react" ... ]

If we have that, no need to change anything related to the solver.

AltGr commented 10 years ago

Hum, I think I broke %{foo+bar:enable}% at some point, without noticing. I'll reintroduce it if it may still be useful ?

AltGr commented 10 years ago

@samoht raises an important point: this all depends on the point at which we choose to articulate between opam's resolution and the package's ./configures. If we don't agree on this there is no point in discussing further details.

We already agree on what is independent on this question:

If I go all the way on the packages side, that's it. I could assume that ./configure detects that ssl is not there and not use lwt. I don't need to add any conflicts, and the packager could still add them to workaround version detection in ./configure.

All the way on the other side, OPAM could have a precise definition of exactly what configurations are required to make a package work, and ensure the consistency of these configurations through upgrades. ./configure's job could be done entirely by OPAM, at resolution time.

We of course are in the middle, and the depopts field is also used to work around limitations of ./configure and give better consistency through OPAM package versions. That's exactly what the added conflicts do, and what the installed-hack was doing incompletely. It's ok but makes the definition of the opam file fields a bit more complicated.

With this in mind, @samoht's proposition of handling this by being more explicit to ./configure to set compilation options, if not the simplest for packagers, has the merit of removing most complexity from the depopts field. It will make it a bit more difficult to detect that cohttp was really compiled with lwt support though.

samoht commented 10 years ago

We can indeed add more feedback to the user (by recording and displaying what was the state of the variables used in the OPAM file when it was compiled for instance).

rdicosmo commented 10 years ago

Thanks Thomas for this clarification... I really did not look into the configuration state variables, it is surely worth investigating.

On Wed, Apr 09, 2014 at 05:39:21AM -0700, Thomas Gazagnaire wrote:

Thanks for looking at this!

The original idea of depopts was the following:

  1. you want a way to express configuration-time state variables (such as if two packages are installed then enable a configure flag) which are computed when a new package is installed
  2. you want a way to detect these configuration-time constraints to recompile the package when needed

As it stands, OPAM uses the so-called filters to express 1. See for instance the %{foo:enable}% https://github.com/ocaml/opam-repository/blob/master/ packages/lwt/lwt.2.4.4/opam#L4 which can also be combined: %{foo+bar:enable}}% is "enable" is both %{foo:enable}% and %{are:enable}% are (otherwise it's "disable").

To recompile such packages when a configuration-time variable change, OPAM uses the depopts field. The language here is a bit more involved, as it can be a full formula with version constraints. So it's a over-approximation of the real set.

As a consequence, if one then installs lwt by hand, there is no guarantee
that
ssl will also be installed, and when recompiling cohttp one gets an error.

not really, the configure step of cohttp checks that both packages are installed (if not, the errors is here).

So after some though, I don't think that we need to encode more stuff in constraints (which are not very expressive anyhow), but we should improve the language to express configuration-time variable, and check that we recompile these packages correctly when they change.

Does it make sense ?

— 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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

rdicosmo commented 10 years ago

On Wed, Apr 09, 2014 at 07:47:07AM -0700, Louis Gesbert wrote:

@samoht raises an important point: this all depends on the point at which we choose to articulate between opam's resolution and the package's ./configures. If we don't agree on this there is no point in discussing further details.

Agreed!

We already agree on what is independent on this question:

• trigger rebuilds when the depopts change. We may over-approximate (rebuild cohttp when lwt changed although we didn't care because we didn't have ssl, for example).

If I go all the way on the packages side, that's it. I could assume that ./ configure detects that ssl is not there and not use lwt. I don't need to add any conflicts, and the packager could still add them to workaround version detection in ./configure.

This would be quite sensible: adding intelligence to the configure part would provide more flexibility. As a use case, I may want to have lwt aside cohttp, and not ssl, and still have opam compile cohttp, which is not possible if we go for the encoding in the package dependencies.

All the way on the other side, OPAM could have a precise definition of exactly what configurations are required to make a package work, and ensure the consistency of these configurations through upgrades. ./configure's job could be done entirely by OPAM, at resolution time.

Indeed: this would be in some sense safer, because writing a depopts is probably simpler than getting the configure right, but it would tightly bind the set of packages installed to the ones used in the compilation phase, which is not necessarily what we want.

We of course are in the middle, and the depopts field is also used to work around limitations of ./configure and give better consistency through OPAM package versions. That's exactly what the added conflicts do, and what the installed-hack was doing incompletely. It's ok but makes the definition of the opam file fields a bit more complicated.

With this in mind, @samoht's proposition of handling this by being more explicit to ./configure to set compilation options, if not the simplest for packagers, has the merit of removing most complexity from the depopts field. It will make it a bit more difficult to detect that cohttp was really compiled with lwt support though.

Considered the points above, one could surely support the idea of keeping the explicitation of implicit conflicts from the depopts, as added in your PR, and pushing into the configure part all the rest.

It it is possible to add proper user feedback when the prerequisites of a configure are only partially honored, as @samoht suggests, I think we would have a very good compromise... something like

Warning: disabling lwt support because

Well, this is just a suggestion, supposing one knows the relevant importance of lwt, ssl and toto, otherwise one could live with a less informative message like

Warning: disabling feature XXX because its prerequisites are not fully satisfied:

Roberto

samoht commented 10 years ago

This would be quite sensible: adding intelligence to the configure part would provide more flexibility. As a use case, I may want to have lwt aside cohttp, and not ssl, and still have opam compile cohttp, which is not possible if we go for the encoding in the package dependencies.

Actually, it was already possible: replace https://github.com/ocaml/opam-repository/blob/master/packages/cohttp/cohttp.0.9.2/opam#L8 by

["ocaml" "setup.ml" "-configure" "--prefix" prefix "--%{lwt+ssl:enable}%-lwt" "--%{mirage-net:enable}%-mirage" "--%{async:enable}%-async"]

(the important part is lwt+ssl)

But now, the configuration bits is hidden in the Makefile (because we switched to use a more complex script, but which could still be extended to support direction from OPAM I think) and this needs @AltGr to repair what he broke :p

So yes, I'm in favour of fixing my ugly hack by:

avsm commented 10 years ago

This sounds like a very workable plan to me. For the record, I'm also currently rewriting the Cohttp build system to split it into multiple OPAM subpackages (like cohttp-lwt, cohttp-async) with the main cohttp package depending on all of them (leaving the user to specifically choose a smaller package if they need). So you'll need to find a new package to debug depopts shortly ;-)

On 9 Apr 2014, at 17:19, Thomas Gazagnaire notifications@github.com wrote:

So yes, I'm in favour of fixing my ugly hack by:

in OPAM:

simplifying the semantics of depopts (ie. only a list of packages, no version constraints) enrich the syntax of state variables (by supporting version constraints, as it is now the case on the command line) give more feedback to the user when some flags are disable/enable in opam-repository

move the conflicts from depopts to conflicts when they are really needed (I guess not very often actually) or simply discard the version constraints to over-approximate the set of packages to reinstall give more configuration hints to the packages when that's possible

rdicosmo commented 10 years ago

Cool, seems we are starting to see some light at the end of the tunnel :-)

BTW, I was quite puzzled by this depopts: statement in cohttp:

$opam info cohttp package: cohttp version: 0.10.0 depopts: async >= 109.15.00 | lwt >= 2.4.3 | (lwt >= 2.4.3 & ssl)

What's the intended meaning of lwt >= 2.4.3 | (lwt >= 2.4.3 & ssl) ?

Also, I suppose you cannot compile cohttp with async and lwt, so what do you do if you have both async and lwt on the system?

Seems to be extra motivation to really separate the configuration logic from the dependency resolution one

2014-04-09 18:22 GMT+02:00 Anil Madhavapeddy notifications@github.com:

This sounds like a very workable plan to me. For the record, I'm also currently rewriting the Cohttp build system to split it into multiple OPAM subpackages (like cohttp-lwt, cohttp-async) with the main cohttp package depending on all of them (leaving the user to specifically choose a smaller package if they need). So you'll need to find a new package to debug depopts shortly ;-)

On 9 Apr 2014, at 17:19, Thomas Gazagnaire notifications@github.com wrote:

So yes, I'm in favour of fixing my ugly hack by:

in OPAM:

simplifying the semantics of depopts (ie. only a list of packages, no version constraints) enrich the syntax of state variables (by supporting version constraints, as it is now the case on the command line) give more feedback to the user when some flags are disable/enable in opam-repository

move the conflicts from depopts to conflicts when they are really needed (I guess not very often actually) or simply discard the version constraints to over-approximate the set of packages to reinstall give more configuration hints to the packages when that's possible

Reply to this email directly or view it on GitHubhttps://github.com/ocaml/opam/issues/1310#issuecomment-39984463 .

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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 320 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

samoht commented 10 years ago

What's the intended meaning of lwt >= 2.4.3 | (lwt >= 2.4.3 & ssl) ?

I think that's a typo. This was not present in previous versions of lwt. You just need/want the clause with ssl.

Also, I suppose you cannot compile cohttp with async and lwt, so what do you do if you have both async and lwt on the system?

actually, yes you can :-) it will just compile and install two different functor instanciations of the library

avsm commented 10 years ago

Any combination of having Lwt, Lwt+SSL, and Async will all compile (with the right subpackages installed if the relevant dependencies exist). I believe the depopts express that...? (not an expert)

On 9 Apr 2014, at 17:31, Roberto Di Cosmo notifications@github.com wrote:

Cool, seems we are starting to see some light at the end of the tunnel :-)

BTW, I was quite puzzled by this depopts: statement in cohttp:

$opam info cohttp package: cohttp version: 0.10.0 depopts: async >= 109.15.00 | lwt >= 2.4.3 | (lwt >= 2.4.3 & ssl)

What's the intended meaning of lwt >= 2.4.3 | (lwt >= 2.4.3 & ssl) ?

Also, I suppose you cannot compile cohttp with async and lwt, so what do you do if you have both async and lwt on the system?

Seems to be extra motivation to really separate the configuration logic from the dependency resolution one

2014-04-09 18:22 GMT+02:00 Anil Madhavapeddy notifications@github.com:

This sounds like a very workable plan to me. For the record, I'm also currently rewriting the Cohttp build system to split it into multiple OPAM subpackages (like cohttp-lwt, cohttp-async) with the main cohttp package depending on all of them (leaving the user to specifically choose a smaller package if they need). So you'll need to find a new package to debug depopts shortly ;-)

On 9 Apr 2014, at 17:19, Thomas Gazagnaire notifications@github.com wrote:

So yes, I'm in favour of fixing my ugly hack by:

in OPAM:

simplifying the semantics of depopts (ie. only a list of packages, no version constraints) enrich the syntax of state variables (by supporting version constraints, as it is now the case on the command line) give more feedback to the user when some flags are disable/enable in opam-repository

move the conflicts from depopts to conflicts when they are really needed (I guess not very often actually) or simply discard the version constraints to over-approximate the set of packages to reinstall give more configuration hints to the packages when that's possible

Reply to this email directly or view it on GitHubhttps://github.com/ocaml/opam/issues/1310#issuecomment-39984463 .

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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 320 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 — Reply to this email directly or view it on GitHub.

Drup commented 10 years ago

I like the approach of enriching the state language, as I did stumble upon the issue when I packaged lilis, but I'm a bit wary of the correctness of build scripts in existing and future packages. Could the testing framework for opam be extended to handle all the combinations of depopts without being too costly ? AFAIK, it's only testing the base dependencies currently.

Drup commented 10 years ago

Also, since we are talking about depopts, a package can't currently explain the use of depots to the user after an install/upgrade. To take a concrete example, In archlinux, when I install a package foo, I will have a message

For the package foo, the following optionnal dependecies are available :
 - bar : Allow to do bar stuff
 - baz : Add the ability to output in the baz format

And the same after an upgrade, if it adds new optional dependencies.

avsm commented 10 years ago

Lwt without SSL will install just the Lwt core library (used by mirage http), so both are valid. SSL requires Unix (for now)

On 9 Apr 2014, at 17:51, Thomas Gazagnaire notifications@github.com wrote:

What's the intended meaning of lwt >= 2.4.3 | (lwt >= 2.4.3 & ssl) ?

I think that's a typo. This was not present in previous versions of lwt. You just need/want the clause with ssl.

Also, I suppose you cannot compile cohttp with async and lwt, so what do you do if you have both async and lwt on the system?

actually, yes you can :-) it will just compile and install two different functor instanciations of the library

— Reply to this email directly or view it on GitHub.

avsm commented 10 years ago

Yes, the tests can be extended, but this needs a command line binary to do so (via opamfu)

On 9 Apr 2014, at 19:11, Drup notifications@github.com wrote:

I like the approach of enriching the state language, as I did stumble upon the issue when I packaged lilis, but I'm a bit wary of the correctness of build scripts in existing and future packages. Could the testing framework for opam be extended to handle all the combinations of depopts without being to costly ? AFAIK, it's only testing the base dependencies currently.

— Reply to this email directly or view it on GitHub.

rdicosmo commented 10 years ago

Thanks everybody for these clarifications: I am now starting to get the full picture of what are the pain points we need to address; let me try to summarise my current understaning and make a few proposals:

All these needs were tangled into the single depopts: line, and there is no surprise if this leads to confusion.

Core Proposal

Fully separate the three issues:

1 goes to a new line "recompile-triggers",

 (just a suggestions, other ideas welcome)

2 goes to a new line "extension-points" (a suggestion, again)

 that lists the features and their conditions, which can now
 be expressed in full boolean logic (a la *BSD ports AFAIR),
 as they will not used for dependency resolution (solved),
 but only to filter specific conditions (checked)

3 goes to the conflicts: line (and nowhere else)

So we could have something like this

package: cohttp depends: .... recompile-triggers: async, lwt, ssl <== (no &, | allowed, just a list) extension-points: "ssl support" ( ssl & lwt >= 2.2.14, ssl & async), \ "async+lwt" (ltw >= 2.2.14 & async) \ "minimal" (lwt & -async & -ssl) conflicts: (async < ...), ...

Here is the underlying idea:

a) any change in state for recompile-triggers, well, triggers a recompilation

b) we compute the set of enabled features that changed in the new state (easy and efficient: just check each formula before and after the update), and we are now pretty able to output nice informative messages for the user, indicating the extension points that are enabled/disabled, as mentioned before in this thread.

Proposal variations:

Having isolated extension points, we can imagine to use them for extra
functionality, for example:

  -> user hints: to compute a suggestion for enabling a feature, but
     beware, with arbitray boolean formulae, there might be exponentially
     many reasons, so this a dangerous bend, not easy, and just written
     here for reference!)

  -> reduce recompilation needs

     if we consider that the extension-points are exhaustive, no change
     in the feature set *and* in the versions of the packages involved in
     the *enabled* feature set means no recompilation is needed

Your feelings on this proposed roadmap?

Cheers

Roberto

AltGr commented 10 years ago

Indeed, this makes things much clearer !

The downside is the loss in terms of compatibility with the existing repos, of course. That is mitigated if we re-use depopts, and I could re-use my depopts-to-conflicts code in opam-admin to do a rewrite (not sure enough packages are impacted to make it worth the time though).

Last: this is quite big to make it into 1.2.0. Unless we choose to wait for the dose release and save the time to test it. Well I've still a bit of debugging to do on the new dev and pinned packages handling.

rdicosmo commented 10 years ago

If we all ok this proposal, I would really give it full priority for 1.2: it is a user and maintainer - visible change that adds important features, and may have positive impact on the package base... delaying it would be a risk.

In that case, for testing dose, I can try to lend a hand (during my night hours :-))

On Thu, Apr 10, 2014 at 02:04:31AM -0700, Louis Gesbert wrote:

Indeed, this makes things much clearer !

• I would have kept recompile-triggers as depopts, because the semantics is actually the same for most packages, which only have simple depopts. This makes the proposal clearer though :) • No automatic conflicts is good, I think : I am generally not fond of tools having that kind of non-obvious cleverness in guessing what I want, esp. when I have a clear way of specifying it. • I am not sure how you use the extension-points: do they define new variables to be used in the build/test fields ? This makes it a bit more verbose but clearer than @samoht's proposal. The idea is the same, compute variables from boolean formulas, which indeed would be useful and rather easy to do.

The downside is the loss in terms of compatibility with the existing repos, of course. That is mitigated if we re-use depopts, and I could re-use my depopts-to-conflicts code in opam-admin to do a rewrite (not sure enough packages are impacted to make it worth the time though).

Last: this is quite big to make it into 1.2.0. Unless we choose to wait for the dose release and save the time to test it. Well I've still a bit of debugging to do on the new dev and pinned packages handling.

— 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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

samoht commented 10 years ago

Ok for changing the semantics of depopts to match 1. Ok for 3. as well. As for extending the semantics of state variables, what about allowing the user to define it's own variables in an OPAM file, using an arbitrary formula and an explanation string ?

For instance (the var- prefix is just a proposal):

var-ssl-support: "Support for SSL" { os != "windows" & "ssl" >= "1.1" & ("lwt" < "4" | "async") } 
build: [ "./configure ... "%{ssl-support:enable}%-enable" ... ]

The state variables are available for all filters (could be useful for applying patches as well, they are recorded for each packages and triggers a recompilation if their value change. Ideally they would deprecate the depopts field, but I think they can live together (as depopts is somehow simpler to use).

dbuenzli commented 10 years ago

So if I understand correctly with this proposal rather than specify version constraints in deps and/or optdepts we specify them in conflicts, i.e. rather than

depopts: { react {< "1.0.0"}  }

we do 

depopts: react
conflicts: { react {>= "1.0.0"}}

shouldn't we then deprecate version constraints in opts and depopts aswell ?

rdicosmo commented 10 years ago

Actually, the proposal does not concern regular dependencies, which are mandatory, and will stay the same, i.e. CNFs with version constraints allowed

Only the old depopts: would be changed into a single list without version constraints, used to trigger recompilation

And any conflict currently implicitly expressed in depopts: will need to be moved to the conflicts: stanza

On Thu, Apr 10, 2014 at 03:00:57AM -0700, Daniel Bünzli wrote:

So if I understand correctly with this proposal rather than specify version constraints in deps and/or optdepts we specify them in conflicts, i.e. rather than

depopts: { react {< "1.0.0"} }

we do

depopts: react conflicts: { react {>= "1.0.0"}}

shouldn't we then deprecate version constraints in opts and depopts aswell ?

— 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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

rdicosmo commented 10 years ago

Keeping the old term depopts: has the advantage of being less disruptive w.r.t. the current state of the repo, indeed. Ok for me

On Thu, Apr 10, 2014 at 02:04:31AM -0700, Louis Gesbert wrote:

Indeed, this makes things much clearer !

• I would have kept recompile-triggers as depopts, because the semantics is actually the same for most packages, which only have simple depopts. This makes the proposal clearer though :) • No automatic conflicts is good, I think : I am generally not fond of tools having that kind of non-obvious cleverness in guessing what I want, esp. when I have a clear way of specifying it. • I am not sure how you use the extension-points: do they define new variables to be used in the build/test fields ? This makes it a bit more verbose but clearer than @samoht's proposal. The idea is the same, compute variables from boolean formulas, which indeed would be useful and rather easy to do.

The downside is the loss in terms of compatibility with the existing repos, of course. That is mitigated if we re-use depopts, and I could re-use my depopts-to-conflicts code in opam-admin to do a rewrite (not sure enough packages are impacted to make it worth the time though).

Last: this is quite big to make it into 1.2.0. Unless we choose to wait for the dose release and save the time to test it. Well I've still a bit of debugging to do on the new dev and pinned packages handling.

— 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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

rdicosmo commented 10 years ago

On Thu, Apr 10, 2014 at 02:41:52AM -0700, Thomas Gazagnaire wrote:

Ok for changing the semantics of depopts to match 1. Ok for 3. as well.

Cool!

As for extending the semantics of state variables, what about allowing the user to define it's own variables in an OPAM file, using an arbitrary formula and an explanation string ? For instance (the var- prefix is just a proposal):

var-ssl-support: "Support for SSL" { os != "windows" & "ssl" >= "1.1" & ("lwt" < "4" | "async" } build: [ "./configure ... "%{ssl-support:enable}%-enable" ... ]

That's quite in line with what I had in mind... The only suggestion is to use a single field with a canonical name, which may contain a list of state variables + formulae, instead of deducing the name of state variables from suffixes of field names.

In terms of functionality, that's equivalent, but for analysing metadata later on, using a specified field name makes things easier.

What about "features" as a field name? Your example would become

features: [ssl-support "Support for SSL" { os != "windows" & "ssl" >= "1.1" & ("lwt" < "4" | "async" }; multi-backend "Enable both Async and Lwt" {"lwt" < "4" & "async" } ] build: [ "./configure ... "%{ssl-support:enable}%-enable" ... ]

The state variables are available for all filters (could be useful for applying patches as well, they are recorded for each packages and triggers a recompilation if their value change. Ideally they would deprecate the depopts field, but I think they can live together (as depopts is somehow simpler to use).

— 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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

AltGr commented 10 years ago

@dbuenzli, yes, restricting depopts to a simple list of package names was in @rdicosmo's proposal.

dbuenzli commented 10 years ago

Le jeudi, 10 avril 2014 à 18:43, Louis Gesbert a écrit :

@dbuenzli, yes, restricting depopts to a simple list of package names was in @rdicosmo's proposal.

Well actually I was thinking about removing that from deps: aswell, so that all version constraints are confined to a single field (conflicts:).

Daniel

samoht commented 10 years ago

I like the features field!

rdicosmo commented 10 years ago

Great! Let's try to write the specs down, then... I'll make a pass tonite and add a draft doc (if I survive my bronchitis :-))

On Thu, Apr 10, 2014 at 10:29:14AM -0700, Thomas Gazagnaire wrote:

I like the features field!

— Reply to this email directly or view it on GitHub.*

rdicosmo commented 10 years ago

Unlike depopts, version constraints in regular (non optional) dependencies is now a well established practice (over 15 years of medatata in hundreds of thousands of packages), and poses no problem for solving dependencies.

Conflicts, on the other side, should be restricted to a minimum, and while it may seem appealing to encode all versions constraints into conflicts from a programming language point of view, when you consider solving complexity it is something to be avoided.

I know this may seem puzzling, as one of course can encode version constraints in deps as conflicts, but when you look at the gory details, you'll see that version constraints in dependencies can be easily encoded as a disjunction of positive atoms under an implication (dual horn formulae, satisfiability in linear time), while conflicts are encoded as negative atoms under an implication, which disrupts the dual horn shape, and brings us back to NP-completeness, hence the need to minimise them.

I hope I do not sound too pedantic with all these details, that are much easier to convey on a blackboard than by mail, I just think it's important to share the knowledge about the deep reasons that underly the choice of a particular representation of dependency medatada :-)

On Thu, Apr 10, 2014 at 10:01:04AM -0700, Daniel Bünzli wrote:

Le jeudi, 10 avril 2014 à 18:43, Louis Gesbert a écrit :

@dbuenzli, yes, restricting depopts to a simple list of package names was in @rdicosmo's proposal.

Well actually I was thinking about removing that from deps: aswell, so that all version constraints are confined to a single field (conflicts:).

Daniel

— 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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

dbuenzli commented 10 years ago

Le jeudi, 10 avril 2014 à 21:08, Roberto Di Cosmo a écrit :

and while it may seem appealing to encode all versions constraints into conflicts from a programming language point of view,

Well it's rather from a usability/readability point of view: there's a single place to lookup for these things when there's a problem.

I know this may seem puzzling, as one of course can encode version constraints in deps as conflicts, but when you look at the gory details, you'll see that version constraints in dependencies can be easily encoded as a disjunction of positive atoms under an implication (dual horn formulae, satisfiability in linear time), while conflicts are encoded as negative atoms under an implication, which disrupts the dual horn shape, and brings us back to NP-completeness, hence the need to minimise them.

Ok, I still have the gut feeling that somehow the conflicts/deps/deptops as they exist are somehow inter-translatable and/or and that it should be possible to recover/repartition one form over the other automatically but I'm not deeply entrenched in the topic. My only wish it that we can have a system that's readable by people that treat the solver as a black box.

I hope I do not sound too pedantic with all these details, that are much easier to convey on a blackboard than by mail, I just think it's important to share the knowledge about the deep reasons that underly the choice of a particular representation of dependency medatada :-)

I don't find it pedantic, I'm glad you take the time to explain the reasons.

Best,

Daniel

rdicosmo commented 10 years ago

As promised, the detailed proposal for metadata evolution is now included in PR 1321

https://github.com/ocaml/opam/pull/1321

you will find the document in doc/design/metadata-evolution

2014-04-10 19:40 GMT+02:00 Roberto Di Cosmo roberto@dicosmo.org:

Great! Let's try to write the specs down, then... I'll make a pass tonite and add a draft doc (if I survive my bronchitis :-))

On Thu, Apr 10, 2014 at 10:29:14AM -0700, Thomas Gazagnaire wrote:

I like the features field!

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

FRANCE. Twitter: http://twitter.com/rdicosmo

Attachments: MIME accepted, Word deprecated

http://www.gnu.org/philosophy/no-word-attachments.html

Office location:

Bureau 320 (3rd floor) Batiment Sophie Germain Avenue de France

Metro Bibliotheque Francois Mitterrand, ligne 14/RER C

GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3

Drup commented 10 years ago

I find the feature field very nice, especially the added documenting value.

(and I concur with @dbuenzli, these detailed explanations on the semantic of package dependencies are very interesting)

rdicosmo commented 10 years ago

On Thu, Apr 10, 2014 at 12:20:48PM -0700, Daniel Bünzli wrote:

I hope I do not sound too pedantic with all these details, that are much easier to convey on a blackboard than by mail, I just think it's important to share the knowledge about the deep reasons that underly the choice of a particular representation of dependency medatada :-)

I don't find it pedantic, I'm glad you take the time to explain the reasons.

Thanks!

Roberto

rdicosmo commented 10 years ago

On Thu, Apr 10, 2014 at 03:06:44PM -0700, Drup wrote:

I find the feature field very nice, especially the added documenting value.

Great!

(and I concur with @dbuenzli, these detailed explanations on the semantic of package dependencies are very interesting)

I am glad to here this... indeed that material is unfortunately not very well known, event if our team did publish quite a wealth of research articles on it.

You can find a short survey of the main concepts in

@inproceedings{Hats2012, author = {Di Cosmo, Roberto and Ralf Treinen and Stefano Zacchiroli}, title = {Formal Aspects of Free and Open Source Software Components - A Short Survey}, booktitle = {FMCO}, year = {2012}, pages = {216-239}, ee = {http://dx.doi.org/10.1007/978-3-642-40615-7_8}, }

Which can be found on my homepage

http://www.dicosmo.org/Publications/Hats2012.html

Roberto