[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

On Drupal8 packaging

Hello world,

  [ Please keep me and David in the replies; we are not subscribed to
    -mentors ]

I don't know if I should be writing this directly to the ftpmasters,
but I'd like to have input by the rest of the project before that. And
I'd also like to know if we are doing it perfectly wrong.

I am working on this together with David Flores, Cc:ed in this
mail. We have taken bits of time to get Drupal8 in a packaged
form. This release is a huge departure from previous Drupal releases —
Debian has packaged Drupal since version 4.5.2 (accepted back in 2005,
according to snapshot.d.o). Each Drupal release can be seen as a new
project, and since version 5 it was so packaged in Debian, because:

- Drupal provides no real, automated migration path between major
  versions; it's up to the sysadmin to resolve.

- Drupal's development cycles are more a project rewrite than an
  evolution. Part of the code is kept, of course, but there are *huge*
  architectural changes.

- And, as every webapp nowadays, it includes swathes of Javascript
  code, bundled in the "main" project.

The deepest reaching (for me) architectural change for D8 is that it
is no longer self-contained, but is built upon a PHP framework
(Symfony) and many related tools. This is, surprisingly, a *good*
thing, as Drupal itself is becoming smaller and easier to grasp for
its own developers, and there is a separation of concerns. BUT it
makes my life as a developer harder.

So, the current situation is:

- drupal8 8.2.1 is packaged, although still with many important
  Lintian warnings, by following the upstream Git tree, and hosted at


  David has been helping me make sense of the Drupal oddities, and
  helping me avoid or route around costly mistakes.

- We started by checking which Javascript libraries are provided by
  Debian with versions compatible with the shipped ones. This was done
  by following the provided core/core.libraries.yml file:


  Sadly, very few libraries comply: Only ckeditor, libjs-jquery-cookie
  and libjs-underscore. For the rest, we will be providing the
  upstream-bundled ones, providing its sources (as they are all
  minified/browserified) in debian/missing-sources.

- Then, the PHP dependencies are based upon an ugly Composer file:


  We have gone through them, and the outlook for using project-wide
  libraries is much better; you can see debian/control for php-*
  packages depended upon. But still, there are way too many PHP
  packages it uses which are not in Debian; we have copied them all
  into debian/vendors, and installing them at install time. It is 15MB
  of... Stuff.

We still have pending documenting all of it in debian/copyright, as
well as some other minor issues. But I want others to confirm if this
is not deemed as excessive and a no-go.

Of course, I understand the "right" answer would be to separately
package each of the complete provided PHP packages. We have decided
against it mainly for the following reasons:

- At this time of the release, we don't want to press on the PHP team
  to package that many libraries (and have them in time for the
  NEW-processing freeze). David is a Drupal guy, I am the Debian guy,
  and I *know* I don't have time to prepare (or properly review and
  upload) all of them as individual packages.

- Even if they are useful as stand-alone libraries, I am wary to
  promise support to them. If they are shipped only as utility
  libraries for Drupal, I can trust and follow Drupal's development,
  and they have a very good track record at replying to any needed
  adequation. Of course, if during the course of the following years
  (between Debian 9 and 10) the PHP team packages the remaining
  libraries and they are kept at a compatible level, I should be
  updating to depend on them instead of bundling.

- According to Drupal's release policies, they might require strict
  dependencies on specific versions. Those versions remain stable over
  the course of a minor release (minor releases happen ≈ every six
  months; 8.2.x has just been opened).

- I toyed with the idea of splitting this into two packages, drupal8
  and drupal8-support... But it gains us very little, if anything at

So... Does this sound sensible? Were you in my place, would you submit
this package to ftp-masters? What would you change about it?

Thanks a lot!

Attachment: signature.asc
Description: Digital signature

Reply to: