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

Re: status update of ocaml 3.06 testing transition.



On Mon, Nov 25, 2002 at 10:45:59AM +0100, Jérôme Marant wrote:
> >Ok ? Ok to which one ?
> >
> 
> The last one, for me.

Ok, ... so let's schedule a date where we have a bit of time and do it.

> >Mmm, you are not in favor of it, right ?
> >
> 
> Currently, from the user-friendliness point of view, this is not a proper
> solution. The user must not have to install <app>-byte. When he wants
> to install <app>, he doesn't care whether it is a bytecode or native
> version.

No, with the current naming scheme and all, this is transparent to the
user.

He does apt-get install spamoracle, and this will work without problem
if the user is on i386 where spamoracle is the native code package or on
m68k where spamoracle is provided by spamoracle-byte, the bytecode
package.

If you want to install the bytecode package on i386 you need to install
it explicitly.

> Now, from the disk space point of view, I'd say, like Joey Hess said (and
> he has often very accurate judgements), it really depends on the size of
> the application. What is good for Coq is not necessarily good for other
> applications. Speaking about, Cameleon, it is a set of small applications,
> so it is not worth it.

Yes, but if it is no more work, why not do it. And also, you get the
benefit of not needing the non native code supporting autobuilders.

That said, if you build bytecode only for cameleon, like stefano does
for some of his package, then this doesnot apply to you.

> >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.
> >
> 
> As I said above, it really depends.
> 
> >Also it would enable native code supporting arches to choose either the

... all my argumentation snipped ...

> >able to force you to package things differently than what you want.
> > 
> >
> Anyway, whatever I say, whatever I prove wrong, you'll modify the policy
> anyway.

Hey, no, don't go that way. I really want to know why you don't like it.

Just you feeling that it is not worth the trouble, and that you don't
have time to adapt the packages, this i would understand if it where the
case, but then you would say, no problem write the policy, and i will
adapt if i have time for it/feel like it.

Now, if you really feel this is not a good thing, then you should say
so. 

Do you use versioned build depends on non-library code or something such
in cameleon ? Is there another reason why you don't feel it would be
easy to do it ? 

Friendly,

Sven Luther



Reply to: