Packaging ocPortal

[Chris Warburton]

Hello everyone, I'm a developer working for a company called
ocProducts[1], and we write a Free Software content management system
called ocPortal[2] which is released under the FSF and OSI approved
Common Public Attribution License.

As long time Debian users we would love to see ocPortal packaged for
Debian, and have decided to devote some effort to getting it packaged
and compliant. In the worst case we can host our own repository, but we
would ideally like to get into main.

The technical responsibility for this lies with me, but I have a few
queries about the process:

1) The PHP Policy Draft[3] is incomplete, containing many sections with
notes like "XXX: .......". How applicable is the information in this
document? Is is out of date and invalid, or is it correct and
up-to-date, except for the incomplete sections?

2) We are considering integrating Debian package generation into our
regular release process, as we already generate packages for
Installatron and Bitnami. The scripts that manage this are kept in
ocPortal's subversion repository[4]. Would anyone recommend a specific
way to do this? Approaches I can think of include generating an
unmodified tarball and patching it in the package; generating a patched
tarball which can be packaged as-is; maintaining a specialised
repository (eg. to integrate with Git packaging processes). Since we
host ocPortal's SVN repository, we would be able to include most
required changes into the trunk, so patching should be minimal anyway.

3) Should we look for approval from debian-legal now or when the
packaging's done? For the record we have audited the source tree and
removed/replaced anything with unknown or unclear licensing, although
these changes are not in the releases on ocportal.com.

4) Does anyone have suggestions specific to packaging PHP Web-apps, or
should I just plough through the new maintainer's guide?

Thanks in advance,
Chris Warburton

[1] http://www.ocproducts.com
[2] http://www.ocportal.com
[3] http://webapps-common.alioth.debian.org/draft-php/html/
[4] http://ocportal.com:81/svn/svn/4.2.x

[sean finney]

Hi Chris,

Post by Chris Warburton
1) The PHP Policy Draft[3] is incomplete, containing many sections with
notes like "XXX: .......". How applicable is the information in this
document? Is is out of date and invalid, or is it correct and
up-to-date, except for the incomplete sections?

Yeah, it's a bit of a shame that it wasn't finished before most
people (myself included) got distracted by other shiny things. For
the most part I think that the draft is "basically" correct, though
very much incomplete. I think there's also a few sections that are
a bit ambiguous (like the package naming conventions for modules vs
libraries).

If there's specific questions or you have suggestions/patches I don't
think anyone would stop you from asking and/or contributing though :)

Post by Chris Warburton
2) We are considering integrating Debian package generation into our
regular release process, as we already generate packages for
Installatron and Bitnami. The scripts that manage this are kept in
ocPortal's subversion repository[4]. Would anyone recommend a specific
way to do this? Approaches I can think of include generating an
unmodified tarball and patching it in the package; generating a patched
tarball which can be packaged as-is; maintaining a specialised
repository (eg. to integrate with Git packaging processes). Since we
host ocPortal's SVN repository, we would be able to include most
required changes into the trunk, so patching should be minimal anyway.

Generally speaking (but TMTOWTDI) most people manage the packaging
related changes seperate from the actual development. In the case that
upstream != packager, it's often even (but not always) a seperate repository,
and otherwise I think the common recommendation is to have "debianization"
branches, usually one per supported distro+release, which branch off of
the relevant tags/commits in the mainline development.

It's not really a show stopper, but in practice it's a lot nicer being
able to have them seperate because packaging and development are typically
orthogonal workflows from each other, and you might end up in a situation
where one ./debian directory to rule them all won't work anyway. But
ultimately, what you do in your own VCS is up to you though, and what you
choose to do isn't going to be subject to any kind of formal review;
this is just more of some experience-based recommendations.

The critical thing (if you want your packages to be accepted into
debian/ubuntu) is that the resulting source package is not "native",
the "orig.tar.gz" that you upload does not contain the ./debian
subdirectory, and instead it is entirely contained in a .diff.gz
(format v1.0) or .debian.tar.gz (format v3.0, probably a better choice).

Post by Chris Warburton
3) Should we look for approval from debian-legal now or when the
packaging's done? For the record we have audited the source tree and
removed/replaced anything with unknown or unclear licensing, although
these changes are not in the releases on ocportal.com.

The -legal list is more "advisory" and in no sense official. I'd only
consult it if you had general questions that you weren't sure of, and even
then expect a number of possibly contradictory statements :)

The ftp-masters will review the contents for copyright/licensing related
stuff, and are usually pretty thorough. This is one of the things that
slows down the acceptance of packages from NEW into unstable. If you want
to speed it up, there's a new semi-standard format for debian/copyright[1]
which I haven't started using myself but I hear is generally liked.

If you're using a lot of 3rd party code, one piece of extra advise would be
to look to see if any of the 3rd party code is already debianized as a
seperate package. If so, it is very very strongly recommended to use the
package instead of your own embedded version. It's not a huge problem if you
*also* have the embedded version in your code, as long as it doesn't end up
being used in the resulting binary packages. It may be that the packaged
version isn't the same as yours, and that might mean you have to jump through
a couple extra hoops to support it, but there is a very strong prejudice
against embedded code copies (largely for security/QA reasons).

Post by Chris Warburton
4) Does anyone have suggestions specific to packaging PHP Web-apps, or
should I just plough through the new maintainer's guide?

The new maintainer's guide probably good to read through, as well as
the official Debian Policy[2], the developer's reference[3],
the Webapps draft document[4] the database application draft policy[5] and
corresponding database setup support package[6]. And don't forget to run
lintian on your resulting source packages, it catches a lot of stuff that
you might otherwise miss.

For more general packaging questions, you might want to try on debian-mentors,
and for finding an upload sponsor you can feel free to ask both there and here,
and you might also try on the pkg-php mailing list if it's a PHP webapp.


HTH :)
sean

[1] http://dep.debian.net/deps/dep5/
[2] http://www.debian.org/doc/debian-policy/
[3] http://www.debian.org/doc/developers-reference/
[4] http://webapps-common.alioth.debian.org/draft/html/ (this is in a similar
state to the PHP draft, though)
[5] http://people.debian.org/~seanius/policy/dbapp-policy.html/
[6] http://people.debian.org/~seanius/policy/dbconfig-common.html/

[Tanguy Ortolo]

Post by sean finney
If there's specific questions or you have suggestions/patches I don't
think anyone would stop you from asking and/or contributing though :)

Assuming there is someone to answer. I proposed modifications to the
webapp policy (or maybe the PHP one, I do not remember) and nobody ever
answered so I condidered these policies as abandonned.

[sean finney]

Hi Tanguy,

Post by Tanguy Ortolo

Post by sean finney
If there's specific questions or you have suggestions/patches I don't
think anyone would stop you from asking and/or contributing though :)

Assuming there is someone to answer. I proposed modifications to the
webapp policy (or maybe the PHP one, I do not remember) and nobody ever
answered so I condidered these policies as abandonned.

Semi-abandonded, yeah, but that's mostly lack of interest/time/headcount.

I took a look back and didn't see anything immediately jumping out
regarding what you're referring to, do you have a link handy?


sean

[Tanguy Ortolo]

Post by sean finney
Semi-abandonded, yeah, but that's mostly lack of interest/time/headcount.

It would be easier to get contributions if there was pointers to the
policies source code or repository.

Post by sean finney
I took a look back and didn't see anything immediately jumping out
regarding what you're referring to, do you have a link handy?

Here: <http://lists.debian.org/debian-webapps/2010/03/msg00004.html>.