Overview
Request 755745 accepted
- Update to 7.68
Maintenance release of the Drupal 7 series. Includes bug fixes
and small API/feature improvements only (no major,
non-backwards-compatible new functionality).
No security fixes are included in this release.
See: https://www.drupal.org/project/drupal/releases/7.68
- Generate drupal7 cron.hourly file in spec file to be able to
use macro for root directory
- drupal7-cron
- Generate apache2 configuration from .htaccess file from
upstream
- drupal7.conf
- Fix she-bangs throughout sources
- drupal-7.x-scripts-noshebang.patch
Cron is a dead-end in openSUSE. It has been deprecated years ago already. It makes no sense to provide both cron and systemd.timer in the same package. This requires both cron and systemd in the same package. And it will require additional configuration options to disable the cronjob.
Having said that, drupal7 will be EOL-ed November 2021, so I guess we can keep this old cruft for a while.
Where is the problem? Where it is standing that cron is dead? Last cron version 1.1.3 came out before three weeks.
And where is a problem with configuration?
You make a foo.timer and a foo.cron. The content in foo.cron should be commented.
When you will use foo.timer enable it with systemctl enable foo.timer. When you will use foo.cron uncomment out the lines in cron and start it with systemctl enable cron.
The user can now self decide what he/she will use.
It has been announced several times that cron should be replaced by systemd.timers. Apparently you missed the following announcement, because in its present state, drupal7 no longer builds in Tumbleweed due to the lack of the BuildRequires: cron (which I added).
http://dominique.leuenberger.net/blog/2019/09/opensuse-tumbleweed-review-of-the-week-2019-37-39/
The whole point is, whether we like it or not, cron is going away in openSUSE. But we'll probably be fine for now and can wait for the EOL of drupal7.
Note that drupal8 doesn't have either cron or systemd.timer for running maintenance tasks. I don't know if this is intentional (I don't use either), but it might be good to check.
Request History
adkorte created request
- Update to 7.68
Maintenance release of the Drupal 7 series. Includes bug fixes
and small API/feature improvements only (no major,
non-backwards-compatible new functionality).
No security fixes are included in this release.
See: https://www.drupal.org/project/drupal/releases/7.68
- Generate drupal7 cron.hourly file in spec file to be able to
use macro for root directory
- drupal7-cron
- Generate apache2 configuration from .htaccess file from
upstream
- drupal7.conf
- Fix she-bangs throughout sources
- drupal-7.x-scripts-noshebang.patch
ecsos declined request
Where is the problem? Where it is standing that cron is dead? Last cron version 1.1.3 came out before three weeks.
And where is a problem with configuration?
You make a foo.timer and a foo.cron. The content in foo.cron should be commented.
When you will use foo.timer enable it with systemctl enable foo.timer. When you will use foo.cron uncomment out the lines in cron and start it with systemctl enable cron.
The user can now self decide what he/she will use.
And why you delete apache2.conf?
adkorte reopened request
The apache2.conf file (just like the cron file) is generated inside the spec file from the upstream sources.
ecsos accepted request
And this should be easier? Think not.
When it would change things in upstream the package use old things. :-(
Why not easily use sed to change this things in cron and apache?
I also wrote the reason for generating the configuration files rather than providing them as separate source files in the changelog.
Did you actually look at the spec file? The /etc/apache2/conf.d/drupal7.conf file is now actually generated from the upstream .htaccess file. A header is prepended with the changes made earlier and a footer to close the file. The reason for doing so is obvious - the old one (bundled as a separate source file) was broken for a while already, because it used a syntax that is no longer usable in newer Apache installations. The fact that the package still builds doesn't mean it is in a usable state (as I found out when I installed drupal7 and it broke Apache).
The same goes for the cronjob. This one never used upstream sources before. Generate these files inside specfiles as much as possible to maximize the use of macros.