[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

proposal: new ocaml dirs schema



----- Forwarded message from Sven Luther <luther@dpt-info.u-strasbg.fr> -----

<snip .changes file for libpgsql-ocaml>

>    * Build-Depends and Depends on postgresql-dev >= 7.2.3

Yes, ...

And postgreSQL has been build for all arches, needing 2 days. So now
that this is fixed, please, let's have a 10 day freeze, So ocaml 3.06
can enter testing. Once that is done, each package can enter testing
separatedly.

Also, notice, i am also thinking of a scheme about moving ocaml
directory to /usr/lib/ocaml/3.06, what do you think about this ? This
would mean a whole recompile of all the ocaml packages, but would enable
us to do side by side installation of different versions of ocaml. 

In this way, when a new release is made (let's say ocaml 3.07), i will
rename the current packages as ocaml-3.06, which will still provide
ocaml-3.06 and ocaml-base-3.06, and have the new ocaml package,
providing ocaml-3.07 and ocaml-base-3.07 roll into testing without
problems of the kind we are having now.

This can only be achieved if all ocaml dependant packages depend on
ocaml-3.0x and ocaml-base-3.0x, and never on ocaml proper.

I would thus use these few days of the ocaml-mini-freeze to discuss this
scheme, and also the native/byte code issue of ocaml executables and
naming of packages.

This would go as follows (for executable foo) :

   o the native version of this package will be called foo, and built on
   arches supporting the native code compiler. Ocaml will provide a file
   listing all native code supporting arches, so you can easily use it
   for your packages. I am afraid you will have to copy this file over
   each time, since it can not be done automatically, i think, but then
   maybe with a clever substitution rule, it can be obtained.

   o the bytecode version of this package will be called foo-byte or
   foo-vm, or some other prefix we feel is more appropriated. It will be
   built arch: all and provide foo. When apt-get install foo is run, it
   will choose the real foo over the virtual foo on arches supporting
   the native code, and will choose the virtual foo on arches where only
   the bytecode version is present. I will test this this WE, and inform
   you, but this is what i was told when i asked the apt maintainers
   about it.

Then there is the issue of package you (the maintainer) believe don't
need to have a native code version. These will simply build the bytecode
version and call it foo. They will be arch: all.

The only bad side of this is that we will create additional dependencies
on ocaml-base, and if ocaml fails to enter testing, so will these
packages. On the other hand, if some day missing build depends will also
be considered for the testing migration, this will be happening anyway,
and missing build-depends should be considered also for testing, or we
might do a release which is not buildable by itself.

The benefits are multiple (less waiting for the buildd and less work for
some of them, less archive bloat. And sharing of the vm provided by
building packages without -custom).

Ok, what do you all think about it ?

Friendly,

Sven Luther



----- End forwarded message -----

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney



Reply to: