Starting work / call for help: Debianizing Drupal 8
I have helped maintain Drupal 7.x in Debian for several years (and am now the leading maintainer). During this last year, I got a small article published in the Drupal Watchdog, where I stated:
What About Drupal 8? Now... With all the hype set in the future, it might seem striking that throughout this article I only talked about Drupal 7. This is because Debian seeks to ship only production ready software: as of this writing, Drupal 8 is still in beta. Not too long ago, we still saw internal reorganizations of its directory structure. Once Drupal 8 is released, of course, we will take care to package it. And although Drupal 8 will not be a part of Debian 8, it will be offered through the Backports archive, following all of Debian's security and stability requirements.
Time passes, and I have to take care of following what I promise. Drupal 8 was released on November 18, so I must get my act together and put it in shape for Debian!
So, prompted by a mail by a fellow Debian Developer, I pushed today to Alioth the (very little) work I have so far done to this effect; every DD can now step in and help (and I guess DMs and other non-formally-affiliated contributors, but I frankly haven’t really read how you can be a part of collab-maint).
So, what has been done? What needs to be done?
Although the code bases are massively different, I took the (un?)wise step to base off the Drupal7 packaging, and start solving Lintian problems and installation woes. So far, I have an install that looks sane (but has not yet been tested), but has lots of Lintian warnings and errors. The errors are mostly of missing sources, as Drupal8 inlines many unrelated projects (fortunately documented and frozen to known-good versions) in it; there are two possible courses of action: <ol><li>Prefered way: Find which already made Debian package provides each of them, remove from the binary package, declare dependency.</li><li>Pragmatic way: As the compatibility must sometimes be to a specific version level, just provide the needed sources in debian/missing-sources</li></ol> We can, of course, first go pragmatic and later start reviewing what can be safely depended upon. But for this, we need people with better PHP experience than me (which is not much to talk about). This cleanup will correspond with cleaning up the extra license file Lintian warnings, as there is one for each such project — Of course, documenting each such license in debian/copyright is also a must.
Anyway, there is quite a bit of work to do. And later, we have to check that things work reliably. And also, quite probably, adapt any bits of dh-make-drupal to work with v8 as well as v7 (and I am not sure if I already deprecated v6, quite probably I have).
So… If you are interested in working on this, please contact me directly. If we get more than a handful, building a proper packaging team might be in place, otherwise we can just go on working as part of collab-maint.
I am very short on time, so any extra hands will be most helpful!
Comments
Stoyan Stoyanov 2016-03-11 10:22:00
Core project(s) always up-to-date patch
Hi Gunnar,
Wasn’t sure where to send this. Here’s a Drupal 8 patch to replace the failing debian_security_warning one from Drupal 7. It will make update checks for core project(s) to always return that no updates are available, which eliminates the warning on the updates page as well as alerts on all admin pages.
$ cat debian/patches/update_compare.patch
Description: Core projects always up to date.
— a/core/modules/update/update.compare.inc +++ b/core/modules/update/update.compare.inc @@ -171,6 +171,10 @@
- Data about available project releases of a specific project. */ function update_calculate_project_update_status(&$project_data, $available) {
- if ($available[‘type’] = ‘project_core’) {
- $project_data[‘status’] = UPDATE_CURRENT;
- return;
- } foreach (array(‘title’, ‘link’) as $attribute) { if (!isset($project_data[$attribute]) && isset($available[$attribute])) { $project_data[$attribute] = $available[$attribute]; </code>
Also, it seems that the settings.php has deviated a bit from the defaults. Drupal 8 now uses data stored in YAML files so it seems to make sense for the package to rename/copy most of the default configs and just add a couple of lines if needed (for example to include dbconfig.php and baseurl.php).
I sent you an email several days ago offering help with packaging Drupal 8, but never got a reply. Please let me know if you still need help.