Re: status update of ocaml 3.06 testing transition.
Sven Luther <luther@dpt-info.u-strasbg.fr> writes:
> 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.
OK, I was wrong.
>> 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.
I don't really care if it would be more work. It is too many package.
Cameleon is about 16 and it is enough and maybe too much.
> That said, if you build bytecode only for cameleon, like stefano does
> for some of his package, then this doesnot apply to you.
No, it is both native and bytecode.
>> 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 ?
I really think that it is turning into a disk space _obsession_.
And it is not a packaging problem at all: it took me a lot of time
to polish cameleon packages and I do provide either a bytecode or
a native version with respect to architectures ; I do consider
the bytecode version as a way to make available an application
on architectures that have no native code compiler. I've never
consider it as some way to save space on Debian servers.
Unlike the current CMI issue, for which I understand we must find
a solution, the disk space problem is administrative.
Disk space is costless, disk space is cheap. Trying to save few
megs is a loss of time.
There are plenty ways of saving space like getting rid of some
of the 10000 Debian package that are not used, useless ; and
maybe getting rid of packages on some architectures: who is really
going to use cameleon on m68k, mips, s390 ?
There are very big packages in Debian like GRASS, OpenOffice.org,
and some others, why should I care?
Why not leaving some kind of freedom to OCaml package maintainers
when it makes sense?
It think we have to face real issues like the CMI problem, maybe
the share objects problem (I'm still not convinced it is save)
and the libdir transition.
Cheers,
--
Jérôme Marant
http://marant.org
Reply to: