Re: Shall we state on naming (again)?
On Fri, Oct 04, 2002 at 07:49:45AM +0200, Sven LUTHER wrote:
> > No, I'm not likely to argue on something that has already been
> > decided. I'm happy with the library naming scheme.
> > I'm just trying to find a solution to a problem that is not
> > dealt in the current ocaml policy.
>
> O come on, it was just a joke, ...
Of course it was, but I was serious.
> > > I don't really have any strong idea about this issue, but remember that
> > > it is always easier not to stray from upstream naming scheme, in order
> > > to not confuse our users. (Well, that is what we decided the last times
> > > we did have this discution).
> >
> > So I'll do the way we agree about.
>
> How else could it be ?
So what's the problem with adding it to the policy since it
is missing.
> > I prefectly understood this. But Makefiles belong to upstream and
> > uptream decided to build standelone applications, which sounds
> > logical to me.
>
> Yes, and no.
>
> Upstream has other constraints and preocupation that we have. They want
> a standalone executable because they have no way of tracking
> dependencies, and thus are afraid of having wrong version of stublibs
> and/or missing ones, and thus are often afraid of shipping custom
> packages. On the other hand, they don't really worry all that much
> about having many many copies of the same things installed, and they
> most definitively don't worry about more arches than just i386.
Right.
> We on the other side already have to modify the Makefiles for support of
> bytecode on arches not supporting the native code compilers, so removing
> the -custom flag by the same way is really not all that much work.
Right.
> Ideally, we would have a install.debian or something such target in the
> upstream tarball (well at least a install.native and a
> install.bytecode.nocustom). Most upstream will accept such things if we
> send them patches, and anyway, we can also handle it in the .diff.gz.
>
> Also, we manage things on a strong system based level, with strong
> version dependencies, which allow us to do things differently, which are
> not possible for the upstream developper.
>
> > > And don't tell me we should build with -custom to avoid that, ocaml-base
> > > is most tiny (Installed-Size: 520Ko), and i don't think it is conformant
> > > with any debian policy to have a copy of this for every bytecode
> > > executable, not to speak duplicating the same package for at least 5
> > > arches.
> >
> > But again, I have to patch all the uptream makefiles in order to
> > achieve this, and I a bit reluctant...
>
> You are just being lazy ...
>
> (well it was a joke, in case you decide to be offended)
Yes, cameleon provides 14 packages.
> More seriously, you have to patch upstream for a bytecode target most of
> the time anyway, so why not do this little more thing at the same time
> (as an added bonus, you can strip non -custom built bytecode
> executables).
>
> Well, i will not repeat what i just said above.
If you want to do such stuff, you need two packages per application anyway.
And I'm not in favor of duplicating the number of packages of cameleon.
Cheers,
--
Jérôme Marant <jerome@marant.org>
<jerome.marant@free.fr>
http://marant.org
Reply to: