Packaging Open Journal System for Debian

[gwolf]

Hi,

Before anything else — Please forgive me, I'm in a hurry and must go in ≤10 min So I'll be brief, and will comment later on.

I have created a Debian package for OJS (see my blog post on the subject, http://gwolf.org/blog/packaging-pkp-oks ... als-system ). I am a Debian Developer, and so far, from the packaging side, it is mostly done. It does address several of the points brought up in this thread, as far as I read it (less than half FWIW). I have talked over with Jerico, and he explained to me I probably should not be using the system copy of ADODB but the modified one - Ok, I'll check that soon (as soon as I have the Bugzilla account).

I have uploaded my packaging as a different branch to the SVN repository. Silly me, I didn't check our WNPP pages for OJS (http://bugs.debian.org/wnpp), where your intentions were already registered (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511879). Jerico and I are, happily, more than happy to collaborate!

I uploaded my work to the gwolf branch of your repository, you can browse it at:

http://svn.debian.org/wsvn/collab-maint ... lf_debian_

Anyway — The main packaging differences I can think of right away are:

• I used DebHelper 7 as a packaging framework, it is more widely accepted nowadays in Debian than CDBS, and AFAICT it is greatly more readable. Of course, it is just an opinion.
• I am using the 3.0 (quilt) source format (http://wiki.debian.org/Projects/DebSrc3.0), which implies the Quilt dependency and makes workflow a bit easier
• I have not yet looked at your debian/patches directory. Besides that, everything should be equivalent to what you have done.
• I did add a patch, which I would appreciate you looked at. Of course, this might be an ADODB issue (among the little details Jerico told me you had patched on it): http://svn.debian.org/wsvn/collab-maint ... _undefined
• debian/watch cannot be reliably used, as it would pull the development (2.3.x) releases. We can later see how this can be solved. Should not be a showstopper, FWIW
• Some directories are a bit different. Should not hurt... I guess
• I do not think we should be performing all that level of configuration from Debconf. OJS is quite auto-installable via its own interface, and explains failures in a very good, predictable way. I am leaving the application ready to be configured by Web. We can talk this over, of course (even better, you have already done the work for it )
• Several minor, stylistic packaging subtleties... which do not impact the end product but the process

That's it for today. Hope to work with you for the future!

[jerico]

Hi gwolf,

Jerico and I are, happily, more than happy to collaborate!

Absolutely!

I uploaded my work to the gwolf branch of your repository

Thanks a lot.

I used DebHelper 7 as a packaging framework

I am using the 3.0 (quilt) source format

Several minor, stylistic packaging subtleties... which do not impact the end product but the process

I completely agree with these decisions. They are clearly preferable to my own choices.

debian/watch cannot be reliably used, as it would pull the development (2.3.x) releases

I agree. When I did the packaging, the 2.3 codeline wasn't released yet. I think we'll have to hard code the current stable line version as a pattern into the watch regex. I can make sure that the pattern will be updated in the package as soon as we release the 2.3 branch as a stable branch.

Some directories are a bit different. Should not hurt... I guess

I'll look into this. I think that my approach is unnecessarily complex. From a security POV it's probably not necessary to separate executable code and static content so strictly as I did. I think I exaggerated a bit in this direction.

I have not yet looked at your debian/patches directory. Besides that, everything should be equivalent to what you have done.

That's where I think that your approach needs fixing. You've discovered one of the ADOdb issues. There are about 10-15 others. Some concern smarty and the 2.3 branch will introduces a custom TinyMCE plug-in alongside other new libraries. I assumed that the Debian FTP masters won't accept a patched version of ADOdb/smarty/TinyMCE in the repository. IMO that's the big issue in packaging OJS. I propose that we look at the bugs in the Debian Packaging category together as soon as you have time and decide what needs to be done. I think it's much faster if I explain the changes to you over Skype/GTalk, ... rather than you having to look through all of them on your own.

Fixing these issues has taken about 80% of my time so far and I'm far from fixing them all. The packaging was quickly done in comparison.

I did add a patch, which I would appreciate you looked at. Of course, this might be an ADODB issue (among the little details Jerico told me you had patched on it): http://svn.debian.org/wsvn/collab-maint ... _undefined

That's one of the more obvious changes that the PKP developers applied to ADOdb. AFAICS your patch doesn't solve the problem, though. We need to maintain the setCharset() functionality somehow, otherwise the code breaks with UTF8 as standard charset. That's the reason why I introduce a compatibility layer in my patches. The idea is to maintain the additional functionality and bug fixes in this compatibility layer outside the ADOdb code base until either PKP finds an alternative solution or ADOdb fixes the issues in the core. This allows us to use the off-the-shelf ADOdb code and at the same time make sure that OJS doesn't break.

I do not think we should be performing all that level of configuration from Debconf.

I assumed that we needed full debconf configuration to be in line with Debian policy. If we don't need it (which is well possible) then I'd of course prefer the web configuration interface as it will also considerably reduce package maintenance effort in the future.

jerico