On Thu, Oct 27, 2005 at 03:52:34PM -0400, Joey Hess wrote: > The dh_python script is a) really too long and b) does not require > grokking of nested functions with 5 parameters that are also influenced > by N globals. > > I need to be able to understand and maintain everything in debhelper, > although I would certinly hope you'd continue to help me maintain > dh_ocaml if it enters debhelper.
Fair enough. You're the maintainer and you have the right to understand
each bit of code.
So, practically, what do you require from dh_ocaml? You mention globals,
but there are no longer globals in dh_ocaml (assuming you mean global
variables). Do you have an (even approximate) bound for the size of the
script? Do you want me to get rid of the fill_ocaml_depends function?
I'm asking to know precisely what are you asking me to do.
> > I don't know if in C the same apply, but in ocaml you wont be able to
> > compile having the -dev package but not the lib. Thus I see no point in
> > letting package maintainer the freedom to make mistakes forgetting the
> > dependency from the -dev to the lib.
> .. except for the -l flag.
No, the -l flag was meant to address packages with non-standard naming.
Of course a DD can use it to cheat ... Anyhow, I already agreed on the
removal of that flag.
> An example you might not have considered is a -dev package that needs a
> tight versioned dependency on a library package, vs one that does not.
> Or a -dev package that will actually work with any of several library
> packages, which were perhaps built slightly differently. I don't know if
> these examples would apply to ocaml.
The first in theory can, the second does not. Actually, in the
non-debian ocaml world there is basically no splitting among -dev and
lib part of a library since everyone links statically in native code.
Almost no one cares about portable bytecode executables. In Debian we
chose the debian-way splitting them enabling binary:all bytecode
executable which depends on binary:arch -lib packages.
Anyway I see your point, and asking DD to add the -dev -> lib dependency
is not much a request. I step back on this point and will remove that
additional feature of dh_ocaml.
> > I understand how this can be a problem, at least from a philosophical
> > point of view. Still it is not a problem from a practical point of view
> > since invocation of dh_ocaml are idempotent: they do nothing on lib
> > packages and they do act on -dev packages.
> It's a problem if anyone writes dh_ocaml -plibXXX-ocaml in their rules
> file.
Well, libXXX-ocaml is just a package on which dh_ocaml has nothing to
do. If you like we can add a warning for this case, or, better a warning
for all packages on which dh_ocaml has nothing to do.
> > I'm fine with removing the -l flag.
> Good. How much does that simplfy the code when you do that?
The is_library and is_binary functions may disappear since they will
reduce at checking against a regexp. The L_PARAMS will go away. The
runtime_of_library can go away as well since, it will reduce to a s///
application.
> > > - exit 0 if $dh{NO_ACT};
> > > This makes --no-act mode useless, which removes an important debhelper
> > > debugging feature.
> > I agree on this as well, do I need to be more verbose just becose NO_ACT
> > is in effect and print additional messages?
> No, debhelper is designed to produce sufficient debugging informtion as
> long as you do all actions doit(), complex_doit(), and other functions
> in Dh_Lib.
Ok, so I simply need to check that no harm is done when NO_ACT is in
effect.
I will wait for confirmation from you before going on implementing the
discussed changes. Last remark: I really do not want to force you
accepting dh_ocaml in debhelper, if you still feel, when we will end
this discussion, that dh_ocaml is not suitable for / too different when
compared to other debhelpers ... I will retract my request and maintain
it away from debhelper.
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
signature.asc
Description: Digital signature
