Re: splitting ocaml-native-compilers
>
> Ok,first argument is the lazyness of debian packagers.
Right. This is possibly an ennoying fact, but this is a *real* fact (you
can also add the ignorance of debian packagers --- there are two many
possible things to know all of them). Disregarding facts about human
nature in software engeenering leads to failure IMHO.
>
> > ocaml-native-compilers, but also I will have to take some time to make a
> > new release of my package if my package is arch-dependent. People will
> > benefit on this new arch only when both have been done. By contrast, if
> > my package is arch-independent, they will benefit from the new arch as
> > soon as it is added to ocaml-native-compilers.
>
> Mmm, maybe a conditional build depend would be nice.
What do you mean by conditional build depend?
>
> > 3) this will be less work for you: make ocaml-native-compilers available
> > on any platform. Just do an "make opt.opt || true". Then if the arch is
> > not supported, the package will just contain no binary. This way, you do
> > not even need to know precisely which arch are supported: when there is
> > a new upstream release, just make it available, if a new arch is
> > supported, the binary will be available to the user.
>
> No, it will be more work for me. The current implementation is easier.
>
I do not understand why?
> > On the other hand, I see two potential problems with this
> > 1) make opt.opt might fail on a supposedly supported arch. If you
> > silently ignore the error, you will not detect the problem immediately.
> \
> YEs, like the ia64 case right now.
>
Right. However, I forgot to mention that this can also be seen as an
advantage: the package will still be available (otherwise it is
unavailable until the problem is fixed). Consider for instance the case
of termination of support for m68k.
> Anyway, i guess there will, in the forseable future, only be coq with such
> problems,
Why? From my experience, Coq is a very good bench for discovering what
the next problems of the caml users will be (we had several times some
problems with Caml we were the only one to have, then some months later
it appeared that others also had the same problem --- we had only a
slight advance...).
> and anyway, most probably therte will be a new release of coq when
> there is a new release of ocaml wityh new arches.
Yes there is often a new release of Coq when there is a new release of
OCaml but
1) this is not always the case (no Coq release for 3.02 unless I am
wrong, and none for 3.03alpha).
2) you miss the point that the list of supported architectures changes
over time: I want my Coq package to work with as much ocaml versions as
possible. In testing, ocaml is 3.02 for the moment. As I wanted Coq to
enter testing as soon as possible, I take care not to make it depend on
ocaml-3.04 (I do not know when ocaml-3.04 will be in testing). So I will
not take the risk to put a dependency over a specific architecture
unless this is really needed. So if I cannot take advantage of
ocamlopt.opt without mentionning specific architectures, well I regret I
will not take advantage of it...
Judicaël.
--
Judicael.Courant@lri.fr, http://www.lri.fr/~jcourant/
(+33) (0)1 69 15 64 85
"Heureux ceux qui savent rire d'eux-mêmes :
ils n'ont pas fini de s'amuser !"
Reply to: