Re: Shall we state on naming (again)?
On Fri, Oct 04, 2002 at 08:49:34AM +0200, Jérôme Marant wrote:
> 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.
(But then, if we have ocaml-foo, then ocamllib-foo or ocaml-libfoo would
be a more logical choice).
> > > > 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.
Someone to write it, and maybe days longer than 24 hours ?
Anyway, i plan to add some substantial things to the policy, once a nice
solution is found to the bytecode-nativecode issue.
> > > 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.
:)))
I like being 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.
But a common upstream Makefiles set, and i guess upstream is responsive
enough so you can coerce him to do the job. (It is after all poor
upstream handling of this that forces us to change the makefiles after
all, that and the missing DESTDIR stuff is the main things that need to
be changed in most ocaml packages, and some missing clean stuff also)
> > 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.
Mmm, yes and no, since two of them are the same.
How else you can handle it without breaking all kind of things on arch
not supporting the native code compiler. Apart from shipping only
bytecode that is.
All in all, if a nice solution to the naming problem is found, then the
solution, even if it is a bit of work (well mostly of the cut&paste kind
anyway), is well worth it.
Friendly,
Sven Luther
Reply to: