Re: splitting ocaml-native-compilers
On Fri, Jan 18, 2002 at 09:43:02AM +0100, Ralf Treinen wrote:
> On Thu, Jan 17, 2002 at 11:48:58AM +0100, Sven wrote:
> > >
> > > Another possibility is that you put an architecture-dependent
> > > build-depends on ocaml-native-compilers. Though what you propose is
> > > probably the better solution.
> >
> > Mmm, ralf, why do you feel a fake package would be better than a architecture
> > dependant build depend ?
>
> The main adavantage to me, as Judicaël explained yesterday, is for
> me that it is much easier to maintain - both for you as for the
No, for me the current solution is simpler, i just add the files to be moved
into ocaml-native-compilers, and copy the dh_movefiles line into debian/rules.
I would have to test the existance of the opt.opt files after the compile, to
move the files only if they exist, or the build process will bomb on me.
That said, it is true that it will vcomplicate things only for me, and makke
things easier for other package maintainers.
But then, the empty pseudo package to simplify a build dependency issue don't
strike me as aesthetically elegant, and i have some doubts abotu it being the
right way of doing this.
Ideally, the build process should be able to use dynamical arch dependant
build depends, and thus test if ocaml provides or no the opt package for a
given arch, and then handle things accordiyngly.
> maintainer of the package which build-depends on ocaml(-opt). For
> you the process could be automatic: if the creation of the
> native compiler version fails then you just create on this architecture
> a paquet which just contains the files in /usr/share/doc, with some
> explanation of whhat happenend in the README (if it is possible to
> detect this situation automatically). But the main advantage is for the
> maintainer of the package which build-depends on ocaml since he just
> would not have to chaneg his package at all when the native compilers
> get available at more architecture.
Mmm,
Again, is this really a gain ?
When a new native code compiler gets available, most probably it will be for a
new release of ocaml, and the library at least will need to be rebuilt. Maybe
even the apps, if things happen like the 3.04 case, and anyway, it is always
best to rebuild with the current version of ocaml, especially if your program
use dynamic linking of .cmo files and such. Sure this is mostly a bytecode
problem right now, but this may change in the future.
And also notice, that you will have to rebuild the package for the new arch
anyway, so adding the propper build depend and making a arch specific rebuild
(version 3.04-4.0.1 and such, i think), would be the best way of doing it.
> That's why I think that it would be a technically better solution.
Mmm, it is not elegant, so i don't think it is techically better. What does
the policy say about empty packages ?
Another idea would be for ocaml to provide ocaml-opt or whatever for the
arches where there is no optimized compiler.
> However, I have doubts know (as Zack) whether the "problem" is
> a real problem.
Mmm, i will have to read Zack's message, which only goes into
debvina-ocaml-maint and not into my inbox, and thus has less priority :)))
Friendly,
Sven Luther
Reply to: