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
collab-maint:
https://anonscm.debian.org/gitweb/?p=collab-maint/drupal8.git
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:
https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/core/core.libraries.yml
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:
https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/composer.lock
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
all.
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