Debian Bug report logs - #328422
please add the dh_ocaml debhelper

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Stefano Zacchiroli <zack@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: please add the dh_ocaml debhelper

Date: Thu, 15 Sep 2005 09:17:56 +0200

[Message part 1 (text/plain, inline)]

Package: debhelper
Version: 4.9.8
Severity: wishlist
Tags: patch

dh_ocaml is a new debhelper developed by me which supports the creation
of packages containing OCaml binaries and libraries.

Please include it in the debhelper package.

Attached you can find a patch against debhelper 4.9.8 which adds it.

Cheers.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)

Versions of packages debhelper depends on:
ii  binutils             2.16.1cvs20050902-1 The GNU assembler, linker and bina
ii  coreutils [fileutils 5.2.1-2.1           The GNU core utilities
ii  debconf-utils        1.4.58              debconf utilities
ii  dpkg-dev             1.13.11             package building tools for Debian
ii  file                 4.12-1              Determines file type using "magic"
ii  html2text            1.3.2a-2            An advanced HTML to text converter
ii  perl                 5.8.7-4             Larry Wall's Practical Extraction 
ii  po-debconf           0.9.0               manage translated Debconf template

debhelper recommends no packages.

-- no debconf information

[dh_ocaml.patch (text/plain, attachment)]

Message #10 received at 328422@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Stefano Zacchiroli <zack@debian.org>, 328422@bugs.debian.org

Subject: Re: Bug#328422: please add the dh_ocaml debhelper

Date: Thu, 27 Oct 2005 13:40:26 -0400

[Message part 1 (text/plain, inline)]

I've reviewed (and rather extensively modified, see attached diff) this
patch. I have the following concerns for including this into debhelper:

- The script is too long and complex. It will be a maintenance burden.

- Why should dh_ocaml automatically add dependencies from -dev packages
  to library packages? This is not automatically done for regular C
  libraries and is a cause of complexity.

- I don't understand the other automatic dependencies listed in the man
  page either. Most of them seem unneccessary to be handled by
  debhelper.

- "(please note that the substvar for libXXX-ocaml will be
  filled while processing libXXX-ocaml-dev)" 

  This indictes that dh_ocaml is broken, the -p, -N, etc switches cannot
  relibably be used to make it operate on a single package at a time.
  This is a requirement for debhelper programs.

- The -l syntax is too complex to be allowed in debhelper both due to
  high learning curve because of all the complexity it adds to the code.
  This is what we have control files with individul, manually edited
  Depends fields for.

- exit 0 if $dh{NO_ACT};

  This makes --no-act mode useless, which removes an important debhelper
  debugging feature.

-- 
see shy jo

[ocaml.patch (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 328422@bugs.debian.org (full text, mbox, reply):

From: Stefano Zacchiroli <zack@debian.org>

To: 328422@bugs.debian.org

Subject: [zack@debian.org: Re: Bug#328422: please add the dh_ocaml debhelper]

Date: Thu, 27 Oct 2005 21:06:20 +0200

I forgot to Cc: the BTS ...

----- Forwarded message from Stefano Zacchiroli <zack@debian.org> -----

Date: Thu, 27 Oct 2005 20:48:13 +0200
From: Stefano Zacchiroli <zack@debian.org>
To: Joey Hess <joeyh@debian.org>
Subject: Re: Bug#328422: please add the dh_ocaml debhelper

On Thu, Oct 27, 2005 at 01:40:26PM -0400, Joey Hess wrote:
> I've reviewed (and rather extensively modified, see attached diff) this
> patch. I have the following concerns for including this into debhelper:

First of all, thanks for the review and for the corrections in the
documentation part.

Then, what of the points below you consider to be showstopper? If we
reach an agreement on what should be dealt with I will be happy to work
on them, otherwise I can keep the maintainance of dh_ocaml outside
debhelper (even if I would of course prefer not to).

Comments on each of your concerns follows.

> - The script is too long and complex. It will be a maintenance burden.

What do you mean with maintainance? I don't think anyone of us debian
ocaml is expecting that you (or the other debhelper guys) will maintain
the dh_ocaml part related to the ocaml logic behind it. I think the only
part up to you will be the debhelper API in case of changes. Of course
we will be available for help if something will break, after all, it's
our packages that will be broken in that case! :-)

Moreover, dh_ocaml is not logner than, say, dh_python, but peraphs
that's a bad example you're not happy with either ...

> - Why should dh_ocaml automatically add dependencies from -dev packages
>   to library packages? This is not automatically done for regular C
>   libraries and is a cause of complexity.

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.

> - I don't understand the other automatic dependencies listed in the man
>   page either. Most of them seem unneccessary to be handled by
>   debhelper.

Perhaps I didn't get the philosophy of debhelper, but I tried to put
there all the dependency handling that follow from being an ocaml
package. In this way ocaml DD should only care about writing a substvar
in debian/control and calling dh_ocaml.

Moreover, for us it is often a problem to deal with maintainers which do
not know anything about ocaml but need to maintainer an application (and
the needed libraries) written in ocaml. Having something like dh_ocaml
would help them and us.

> - "(please note that the substvar for libXXX-ocaml will be
>   filled while processing libXXX-ocaml-dev)" 
> 
>   This indictes that dh_ocaml is broken, the -p, -N, etc switches cannot
>   relibably be used to make it operate on a single package at a time.
>   This is a requirement for debhelper programs.

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.

I'm of course open to suggestion on how to solve this issues, since I
have not wonderful idea: in order to compute dependencies of the lib
package I need info which are available only in files installed in the
-dev package. This naturally adds a causal constraint: do -dev package
first, then lib one.

> - The -l syntax is too complex to be allowed in debhelper both due to
>   high learning curve because of all the complexity it adds to the code.
>   This is what we have control files with individul, manually edited
>   Depends fields for.

I agree, I added that flag to overcome a limitation in a package of
mine which does not follow the libxxx-ocaml-dev convention, but it would
be better to rename the package.

I'm fine with removing the -l flag.

> - 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?

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,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. -!-



----- End forwarded message -----

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,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. -!-

Message #20 received at 328422@bugs.debian.org (full text, mbox, reply):

From: Stefano Zacchiroli <zack@debian.org>

To: Joey Hess <joeyh@debian.org>

Cc: 328422@bugs.debian.org

Subject: Re: Bug#328422: please add the dh_ocaml debhelper

Date: Thu, 27 Oct 2005 22:33:47 +0200

[Message part 1 (text/plain, inline)]

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
zack@{cs.unibo.it,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 (application/pgp-signature, inline)]

Message #25 received at 328422@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Stefano Zacchiroli <zack@debian.org>

Cc: 328422@bugs.debian.org

Subject: Re: Bug#328422: please add the dh_ocaml debhelper

Date: Thu, 27 Oct 2005 18:43:58 -0400

[Message part 1 (text/plain, inline)]

Stefano Zacchiroli wrote:
> 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?

My criteria are that I have to be happy with the code for it to go into
debhelper.

I want you to take my feedback into account and where it convinces you
to change dh_ocaml, do so. Hopefully the result will be better liked by
both of us.

> > > 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.

Ok then the problem is someone who writes dh_ocaml -plibXXX-ocaml-dev in
their rules file.

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 328422@bugs.debian.org (full text, mbox, reply):

From: Stefano Zacchiroli <zack@debian.org>

To: Joey Hess <joeyh@debian.org>

Cc: 328422@bugs.debian.org

Subject: Re: Bug#328422: please add the dh_ocaml debhelper

Date: Fri, 28 Oct 2005 08:48:58 +0200

[Message part 1 (text/plain, inline)]

On Thu, Oct 27, 2005 at 06:43:58PM -0400, Joey Hess wrote:
> > 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.
> Ok then the problem is someone who writes dh_ocaml -plibXXX-ocaml-dev in
> their rules file.

It does what is supposed to (act on libXXX-ocaml-dev) and it also create
substvar for libXXX-ocaml. What I can do to avoid the latter part is to
store that info somewhere (a file in debian/ perhaps) and fill the
substvar only when dh_ocaml is invoked on libXXX-ocaml. Such a behaviour
is acceptable for me. Is it for you as well?

Still, the causal requirement that dh_ocaml must be invoked first on the
-dev part remains.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,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 (application/pgp-signature, inline)]

Message #35 received at 328422@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Stefano Zacchiroli <zack@debian.org>

Cc: 328422@bugs.debian.org

Subject: Re: Bug#328422: please add the dh_ocaml debhelper

Date: Fri, 28 Oct 2005 13:14:17 -0400

[Message part 1 (text/plain, inline)]

Stefano Zacchiroli wrote:
> Still, the causal requirement that dh_ocaml must be invoked first on the
> -dev part remains.

There are rules files such as debhelper's example rules.multi2 where
this is not the case and any package can be built indenpendant of any
other, so that is not acceptable.

(Removing the dependency generation code you plan to remove won't change
this?)

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 328422@bugs.debian.org (full text, mbox, reply):

From: Stefano Zacchiroli <zack@debian.org>

To: Joey Hess <joeyh@debian.org>

Cc: 328422@bugs.debian.org

Subject: Re: Bug#328422: please add the dh_ocaml debhelper

Date: Sat, 29 Oct 2005 10:51:02 +0200

[Message part 1 (text/plain, inline)]

On Fri, Oct 28, 2005 at 01:14:17PM -0400, Joey Hess wrote:
> > Still, the causal requirement that dh_ocaml must be invoked first on the
> > -dev part remains.
> There are rules files such as debhelper's example rules.multi2 where
> this is not the case and any package can be built indenpendant of any
> other, so that is not acceptable.

Ok.

> (Removing the dependency generation code you plan to remove won't change
> this?)

I need to think at it a bit more, but I've reconsidered the issue in the
last days and I've found an viable alternative. Basically, in order to
compute depdencies I need a list of ocaml object from which extract
them. In the dh_ocaml implementation we are discussing that list is
extracted using find on the -dev tmpdir after installing the objects.
That is the source of the causal dependency: I need to _install_ the
-dev package before being able to use dh_ocaml on the lib one.

As an alternative I can read the objects directly from the package build
dir (in that case probably not with find, but letting the DD specify
them via a file in debian/). In that case dh_ocaml could be invoked
independently on the -dev and lib packages (at the additional cost of
recompiling dependency maybe, but this is up to ocaml-md5sums).

Still, in that scenario I will need to build (meaning: what is usually
done in the "build" debian/rules target) before being able to use
dh_ocaml on any of the -dev/lib packages (i.e. one build target on which
two binary targets depend). Would that be acceptable?

Mumble mumble ...

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,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 (application/pgp-signature, inline)]

Message #45 received at 328422-done@bugs.debian.org (full text, mbox, reply):

From: Stefano Zacchiroli <zack@debian.org>

To: 328422-done@bugs.debian.org

Subject: Re: Bug#328422: please add the dh_ocaml debhelper

Date: Thu, 15 Oct 2009 20:01:08 +0200

On Thu, Sep 15, 2005 at 09:17:56AM +0200, Stefano Zacchiroli wrote:
> dh_ocaml is a new debhelper developed by me which supports the creation
> of packages containing OCaml binaries and libraries.
> 
> Please include it in the debhelper package.

It is now evident that we, Debian OCaml Maintainer, currently prefer to
keep dh_ocaml (which in the meantime has been rewritten a couple of
times) in our own, OCaml-specific, helper package: dh-ocaml.  While it
respects the Debhelper API and is hence supposed to be a good citizen in
the debhelper family, keeping it separately would ease maintenance on
both sides.

I'm therefore closing this bug report.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

Send a report that this bug log contains spam.