Re: status update of ocaml 3.06 testing transition.
On Mon, Nov 25, 2002 at 10:00:30AM +0100, Jérôme Marant wrote:
> Sven Luther wrote:
>
> >Hello everybody,
> >
> >Ok, time for a new weekly status report of the ocaml 3.06 transition.
> >
> >Well, glibc 2.3.1 is a mess, i guess ome of the RC bugs have even been
> >closed in -5, but not in the BTS, but i may be wrong, i was hoping that
> >a new glibc was being uploaded after this WE BSP.
> >
> >Anyway, i propose here, if we all (well mostly jerom and stefano) agree,
> >that we postpone the mini-freeze, until such a time that glibc 2.3.1
> >migrates to testing, and then we start it again.
> >
> >
>
> Yes.
Ok, if stefano agrees, then let's go with it.
> >We also need to take a decision for the libdir move :
> >
> >
> > o wait for glibc 2.3.1 to enter testing.
> >
> > o choose a date where we can dedicate an hour or so to our packages,
> > and do it.
> >
> >
>
> OK.
Ok ? Ok to which one ?
> >The first option would be safer, but as the sarge release nears, we may
> >loose the oportunity (and benefit) of it, not that i have any idea of
> >the sarge release date (there was speak of a 6 month release scheme
> >though).
> >
> >
>
> Please, don't count on a near release. It is always announced as approaching
> but in fact, releases are always delayed.
Sure, but the longer the testing, the better the package, and if sarge
is too delayed, there may be an ocaml 3.07 released before it, and we
may want to migrate.
> >The second option would be my personal choice, but i need concensus to
> >go with it.
> >
> >Notice that it will only hinder new installs, and not cause any problem
> >when upgrading, as moved packages will only get upgraded when all
> >installed packages are ready (that is have been rebuilt for
> >ocaml-3.06-1).
> >...
> >The only point is that i need to get confirmation from the policy people
> >that the feature of dpkg/apt we use will be policy approved, that is
> >that apt will prefer a real package over a virtual one anytime there is
> >such a thing.
> >
>
> Anyway, it will only happen is sarge+1, like any new feature in APT and
> dpkg.
Yes, but it still may be handy to have an official approbation of this
way of doing things.
> >Anyway, i will add the new nativecode/bytecode scheme to the next
> >version of the policy, so maybe it will be good for all of you packaging
> >ocaml applications (as opposed to libraries) to have a look at the
> >spamoracle package.
> >
>
> I think we already add a discussion about this and also on -mentors, and
> Joey Hess told us that it is not necessarily a problem. It really depends on
> the size of applications. This is why I won't use this for cameleon.
> I'd propose that not to be mandatory.
Mmm, you are not in favor of it, right ?
I propose to make it mandadtory only for apps building native code, the
apps doing only bytecode are fine as they are.
The benefit are more than just space saving though, in particular, you
will no more wait for the mipsel or m68k autobuilder to build your
packages, and they will be ready for testing earlier.
Also it would enable native code supporting arches to choose either the
native code or the bytecode ones (like advi being broken on ia64 and
native code, due to a too big array, but then maybe i should disable the
native code compiler on ia64 instead).
Also, it is only a little change, and not problem at all for the users.
look at what i did for spamoracle :
debian/control :
Package: spamoracle
Architecture: alpha arm i386 ia64 powerpc sparc
Depends: ${shlibs:Depends}
Conflicts: spamoracle-byte
Replaces: spamoracle-byte
Package: spamoracle-byte
Architecture: all
Depends: ${shlibs:Depends}, ocaml-base-3.06
Provides: spamoracle
Conflicts: spamoracle
Replaces: spamoracle
debian/rules :
build-stamp:
# Add here commands to compile the package.
$(MAKE) OCAMLC=ocamlc spamoracle.byte
if [ -x /usr/bin/ocamlopt ]; then \
$(MAKE) spamoracle; \
fi
...
install:
# Add here commands to install the package into debian/advi.
if [ -x /usr/bin/ocamlopt ]; then \
$(MAKE) install DESTDIR=$(CURDIR)/debian/spamoracle; \
fi
$(MAKE) install.byte DESTDIR=$(CURDIR)/debian/spamoracle-byte
...
binary-indep:
...
dh_strip -i -Xspamoracle
...
And that is it.
Sure, it would be interresting to see how it scales to other packages
(like cameleon or coq) but i think you will not really need to do any
more work than what you already do to support bytecode build on arches
not supporting the native code compilers.
So, is there another reason for your objection ? If yes, i would really
like to know before i finalize the draft. The only problem i might see
with more complexe package would be about versioned virtual dependencies
not working, but again, this supposes that we really use versioned
depends, not only on libraries but also on app packages. Is this the
case ?
Anyway, there is no way something i write in the policy document will be
able to force you to package things differently than what you want.
Friendly,
Sven Luther
Reply to: