Re: status update of ocaml 3.06 testing transition.
On Mon, Nov 25, 2002 at 09:53:56PM +0100, Jérôme Marant wrote:
> 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.
So, you agree with the scheme ?
> >> 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.
Well, but it is the exact same packages, the only difference is that you
build all 2*16 of them on your box, while in the current system, you
build 16 yourself, and the 16 other are built by the autobuilders.
(Well, maybe less than 16, since i don't think all of those 16 are apps,
some may well be libraries, but then i may be wrong).
And anyway, do you really consider that a native code package on i386
contains the same thing as a bytecode package on m68k ? This is not
really exact, for one thing, they have different dependencies, which is
easier handled with the native/byte code separation than in the
traditional way (using explicit substitution genereation as argument to
dh_gencontrol, as is done for the ocaml-best-compilers stuff).
> > 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.
Ok, ...
> >> 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_.
Well, as Stefano said, the disk space thingy is only one of the issues,
and it is rather minor (unless we speak of coq). The real issue is the
autobuilders, and i am sure the m68k autobuilder maintainer will agree,
i am sure coq uses many hours (maybe even days) to build on it. (I guess
even ocaml will need many hours on it, but there we have no choice).
> 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.
But what about the mirroring bandwith.
> 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?
XFree86 ? :))))
Sure, sure, but this is out of our hands, and also, the biggest of those
are arch: all, and thus don't need to be many versions of them.
> Why not leaving some kind of freedom to OCaml package maintainers
> when it makes sense?
No problem, like i said, the policy document is a goal to obtain, i have
no force to make it implemented (mmm, bad phrasing here).
> 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)
Huh, could you tell me which of the problems you call the share object
one ? The part of my .cmi thingy proposal relative to shared objects,
or the splitting of the dll.so into their own package ?
> and the libdir transition.
Yes, but then, the bytecode/native code splitting is an app thingy, i
can write it in the policy, and everyone can go at doing it
independently of any other stuff going on in debian/ocaml. If you do it,
fine, if you don't, fine (but you should accept NMUs for doing it). It
really has no impact on the rest of the packages, apart maybe the
versioned dependency issue, that is why i would really like to know if
someone is using a versioned dependency on any of the ocaml apps (not
libs).
Friendly,
Sven Luther
Reply to: