[Debichem-devel] Looking for sponsor to promote a new package OSRA

[Dmitry Katsubo]

Hi Daniel,

On 19/12/2014 17:49, Daniel Leidert wrote:
>> Phh. A bit difficult for me to catch. The debian packaging is part of
>> upstream and I can commit there. I can create GitHub repo to keep Debian
>> part -- but let's discuss what benefits it brings. I that case I would
>> vote for moving of whole upstream to GutHub -- it simplifies pulling
>> patches. Ah, I see that there is another replica:
>>
>> https://github.com/metamolecular/osra.git
>>
>> I am now not sure how to handle this to make everyone happy. I CC to
>> Igor - maybe he would have something to add.
> 
> Well, I'm perfectly ok, if you keep the packaging stuff in upstreams SVN
> repository. I could then add an svn:external definition to the debichem
> SVN repsoitory for OSRA. The downside is, that only you can change files
> then. As long as you are prepared and willing to maintain OSRA, I can
> live with that.

Yes, I am willing to maintain OSRA package. How well I am prepared -
that is difficult for me to judge. Time will show.

I have looked through of what is now currently in [1]. Everything is
pretty straightforward, except dependency "cimg-dev". I didn't know this
library is part of Debian, but it requires some changes in OSRA upstream
to use it. There will be also a version jump from 1.2.7 to 1.4.9. And
also OSRA will be more difficult to build after I remove CImg.h from
upstream. Daniel, Igor, what do think?

> My main critics atm are, that you are using files, that first have to be
> altered, to build the Debian package (debian/control.in and
> debian/rules.in). Especially the last is uncommon. So why do you do
> that?

I wanted the e.g. @LIB_MAJOR_VERSION@ to be controlled by autoconf
script. The problem is that is library major version is changed, then
libosra1.install should be renamed to e.g. libosra2.install. How is it
possible to keep version management in one place / to automate that?

> We need a fix for #582575 before we can proceed. I'm not in favour of
> overruling Cosimo.

Completely agree with you.

> He made some points. OSRA uses a header file, that isn't likely to be
> available on any Linux system. Why does it do that?

Absolutely. GOCR was initially designed as CLI utility. Later Makefile
was added a rule to produce .a library (for static linking), but
original Makefile does not install include files (.h) at all:

105: install: all
121: 	# ToDo: not sure that the link will be installed correctly
122: 	#$(INSTALL) $(INCLUDEFILES) $(DESTDIR)$(includedir)

Obviously I cannot use library without headers. Now, OSRA uses the
function pgm2asc() declared in pgm2asc.h. Here comes the dependency tree
for the inclusions:

- pgm2asc.h
  - pnm.h
    - config.h
  - output.h
    - gocr.h
      - unicode.h
  - list.h

Yes, they are not likely to be available on any Linux system :) One need
to install GOCR, but also say something like this to compile OSRA:

osra$ ./configure --with-gocr-include=../gocr/src

Back to what Cosimo noted in bug #582575:

On Wed, 25 Jul 2012 Cosimo Alfarano wrote:
> Although, the patch would make "public" something that does not seem to
> be intended to be public.

I am not sure what from that dependency tree is "not intended to be
public". In my opinion, config.h is good candidate for being out, but
that requires even more patching of the source by e.g. myself. But I
would like *not* go each structure or constant in headers and decide, if
it should be exposed to public or not.

Perhaps Cosimo or Joerg have something to add.

On Wed, 25 Jul 2012 Cosimo Alfarano wrote:
> Plus, it would make OSRA only compilable against Debian or any other
> system which applies a similar patch, which is not really preferable,
> IMHO, unless ORSA is meant only to work on Debian.

I can't see how can I help here. Either patches are in upstream, or are
in debian/patches. Indeed, if one needs to compile OSRA, he needs to
compile and install all prerequisites, including GOCR. And he will
either need to take a patched version [2] or patch it himself or apply
necessary changes by hand.

> Can OSRA be changed to figure out things on runtime? Did you try to
> contact gocr upstream and ask for making the relevant header files
> public?

First, I can't get what OSRA can figure out on runtime. Header files are
needed during compile time. Second, it's just a technical question: Who
will install headers: Makefile in upstream, or
debian/libgocr-dev.install? If Joerg will push this to Makefile - great,
if not - the instructions will continue leaving in
debian/libgocr-dev.install

> Yeah well, I don't feel that it's reasonable to "force" things here.
> Plan B might also be to fix OSRA to not make use of a private header
> file.

I am very happy to fix OSRA. I would do it immediately once I had a plan
to make it better :) Let's have a look at src/gocr.c from GOCR   (I have
removed unrelated lines):

344: int main(int argn, char *argv[]) {
351:  job_init(job);
362:    job_init_image(job);
364:    mark_start(job);
373:    pgm2asc(job);
375:    mark_end(job);
385:    job_free_image(job);

Will anybody argue that functions listed here are essential to use the
library, hence they should be a part of public API? OSRA uses no more
than that API.

On 19/12/2014 04:41, Igor Filippov wrote:
> I am afraid I am exactly the worst person to ask.
> I hate git and github and don't want to touch either.

Igor, thanks for your opinion. I am personally OK with SVN. Until the
development team is tiny, management is pretty simple. But how to manage
access if team grows? Will you take it over? In Git you don't have to
worry about that.

[1] http://anonscm.debian.org/viewvc/debichem/wnpp/osra/debian/
[2] http://sourceforge.net/projects/osra/files/gocr-patched/

-- 
With best regards,
Dmitry