Re: ocaml-tools depends on ocaml-3.01
Sven> as we are pretty sure that ocaml bytecode will surely not be
Sven> compatible with ocam l3.02.
Sven> Because the virtual machine was upgraded, and the 3.00 bytecode
Sven> is no longer compatible with the 3.01 virtual machine. I am not
Sven> sure, but i guess this is also what will happen when 3.02 is
Sven> released.
Sven> I may be wrong here, if so please proove it to me
Sorry, I don't have 3.01 yet, so if you say it's incompatible it
probably is.
Sven> In any icase it doesn't cost much to rebuild the libraries,
Sven> especially as many of them did see a new release together with
Sven> 3.01, and woody is not yet released.
itz> 3.00. Just because 1 library (ocamldot) turns out to break, is
itz> it a reason to force _all_ ocaml related packages to be upgraded
itz> in lockstep:
Sven> You surely have a fast connection, so what do you complain
Sven> about, just run a apt-get upgrade in the background, and that's
Sven> it.
Sven> ocaml (>=3.01), ocaml (<<3.02)
itz> Like Georges, I don't like this. We need the >= _for
itz> ocaml-tools_, and that's it. Not for other libraries unless they
itz> really break, and nothing about 3.02 until it comes out and can
itz> be tested.
Sven> Well, but then _if_ the passage from 3.01 to 3.02 breaks the VM
Sven> compatibility, thing that may, or may not, happen, we have no
Sven> way to enforce that the new ocaml packagfe is not used with
Sven> older (incompatible) libraries, or even bytecode. And seeing
Sven> that new ocaml releases are far between (well it is more or less
Sven> 1 year since the 3.00 release that 3.01 was released), this is
Sven> not so much of a cost. Allways keep the long term in mind.
It's not just about my downloading convenience. With the scheme you
propose, all ocaml-related packages will always have to be at exactly
the same compiler level at the time of a Debian release. Are you sure
you want to keep track of that? And what about other maintainers?
itz> We can always add conflicts to the ocaml 3.02 package to force
itz> uninstallation of the breaking libraries.
Sven> So you would like me to add a _long_ list of conflicts to the
Sven> ocaml package ? a list which may grow as time pass ? And
Sven> release a new ocaml package each time that a new library
Sven> appears, as to list it ?
Sven> This is not the way of least effort, don't you think ?
Not _every_ old library needs to conflict, only those that break. And
the conflict is added at the time somebody complains about the
breakage.
That's what I would do, obviously I am in no position to impose my
views on you. It just feels like your scheme abuses the
dependency/conflict mechanism for purposes other than true
dependencies.
--
Ian Zimmerman, Oakland, California, U.S.A.
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.
Reply to: