Re: Packaging ocPortal
Hi Chris,
On Mon, Apr 18, 2011 at 01:26:38PM +0100, Chris Warburton wrote:
> 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 :)
> 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).
> 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).
> 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/
Reply to: