[Pkg-octave-devel] Filing ITPs for the octave-forge pkgs

[Rafael Laboissiere]

* Ólafur Jens Sigurðsson <ojsbug at gmail.com> [2008-02-28 03:33]:

> On Wed, Feb 27, 2008 at 10:25:00PM +0100, Thomas Weber wrote:
> > 
> > Just to be clear on this:
> > 
> > 1.) I don't know Perl and don't intend to learn it. It feels strange to me
> > that we need a scripting language in order to provide packages for a
> > different scripting language (what would you think if the Perl group used
> > Python for their scripts?).

Well, we are already heavily using Perl through debhelper.  BTW, this is the
case of the Python packages too, which use dh_python.  Perl is so pervasive
in Debian...

One of the scripts of octave-pkg-dev is octave-pkg-dev.pl, which is an
extension of debhelper, responsible for the creation of the postinst and
prerm scripts, as well for dealing with the substitution variable
${octave:Depends}.  I do not know if it is easy to write this script in
another scripting language than Perl.

That said, what is important for now is the interface. The language in which
the internals are coded is a side issue.  Let's agree on the interface;
please, comment on the following scheme.  With the current octave-pkg-dev in
SVN, the steps for making a new octave-forge package are:

1) Add build-dependency in debian/control (this should pull in debhelper,
   cdbs, and octave*.*-headers):
   
   Build-Depends: octave-pkg-dev, libsomething-dev
   
2) Add a single line to debian/rules:

   include /usr/share/octavc/debian/octave-pkg-dev.mk
   
3) In debian/control, depend on the appropriate variables:

   Depends: ${shlibs:Depends}, ${octave:Depends}
   
Is this okay with you?   

> > 2.) get-oct-pkg-src.pl has 45 lines of Perl code in order to download a
> > package. The very first line of that code is already a mystery to me.
> > Octave's watch file has 2 lines, one being the watch file's version.

Yes, you are right, I duplicated many of the functionalities of uscan in
that script.  I will think a little bit further about this.  However, notice
that uscan would generate a wrong orig.tar.gz tarball for us.  For the
octave-forge packages, we need a tarball inside a tarball.

Note that this script is totally marginal in octave-pkg-dev.  It is just a
convenience script for package developers, who can simply ignore it.  I
wrote it in order to show the cookbook I posted in the mailing list.

> > 3.) octave-pkg-dev.mk.in has about 30 lines of code. I believe this means we
> > are stretching the *C* in CDBS (that actually stands for "common") quite a bit.

Yes, this is exactly what octave-pkg-dev is meant to do.  We are extending
not only CDBS but debhelper too.  The goal is to simplify the packaging work
(see the three steps for package creation above).

> > With that said, I'm fine with the current setup. Just don't expect me to ever
> > touch it -- I simply don't understand it.
> 
> Yes, I partly agree with you there, the perl scripts are cryptic but I
> am willing to learn them and follow up on this matter provided that I
> have the patience to do so :-) (at the moment I don't have to much
> time for this, trying to get some paperwork done for my offline world).
> 
> I say this is fine as long as we get someone (I am willing, but it
> will take time and I will need help from you Rafael) to take care of
> this in the future.

Come on, guys, don't make me fell like a dinosaur :-)

Anyway, I am fully sympathetic with your concerns.  I am happy I know Perl
already and am not forced to learn it ;-).  Although I am currently learning
Python and Ruby, Perl is the scripting language that allows me to get the
job done quicker right now.

I will be happy if we switch to another scripting language for
octave-pkg-dev, provided that (1) it is not Tcl and (2) someone else write
the scripts and is willing to maintain them.  I will take the maintenance
responsibility of octave-pkg-dev for now.

-- 
Rafael