Bug#1034630: ITP: serious-engine -- game engine developed for the classic Serious Sam games
Package: wnpp Severity: wishlist Owner: Sébastien Noel X-Debbugs-Cc: debian-devel@lists.debian.org, sebast...@twolife.be * Package name: serious-engine Version : 0~git20230405 * URL : https://github.com/ptitSeb/Serious-Engine/ * License : GPLv2 Programming Lang: C++ Description : first-person shooter game engine The serious-engine serve as the base for two games developed by Croteam and originally published in 2001 & 2002 : The series follows the adventures of protagonist Sam "Serious" Stone and his fight against the forces of the notorious extraterrestrial overlord Mental, who seeks to destroy humanity. This package alone isn't of any use; it only contains the game engine, you will need a copy of the original game for this package to be useful. This can be purchased from GOG.
Upgrade package from init script to Systemd, move config folder
Hello! I am in the process of updating/upgrading a package from an init.d service to a Systemd service. Are there any recommended guidelines for this process? Looking through some current packages I see that a lot of them have both an init script and a Systemd service in their debian folder. Do dh_installsystemd and dh_installinit handle this smoothly by default if both files exist? When upgrading the package on a machine will it stop the init service and start the Systemd service? The original config, postinst, and init script also configure some debconf values that are not needed anymore. What is the best way to remove those settings without depending on the debconf package? This package also stores its configuration in /var/lib/packagename and it should really be in /etc/packagename. Where is the best place to deal with auto-migration? Should this go in postinst or is there a debhelper that I should use? Thanks! Perry Naseck
Re: Upgrade package from init script to Systemd, move config folder
On 4/20/23 14:48, Perry Naseck wrote: Hello! I am in the process of updating/upgrading a package from an init.d service to a Systemd service. Are there any recommended guidelines for this process? My generic advice would be: start your thinking from a perspective of "how should this work in systemd anew", not "how do I 1:1 convert the init.d unit". That is, start in a "systemd native" approach. You may need to pull back from that for backwards compatibility reasons, or consistency with the init.d unit or whatever (and I maintain a package that is that way), but make those decisions intentionally. Looking through some current packages I see that a lot of them have both an init script and a Systemd service in their debian folder. Do dh_installsystemd and dh_installinit handle this smoothly by default if both files exist? In my experience, if the files are name the same (i.e. /etc/init.d/foo and /lib/systemd/system/foo.service), everything should Just Work, both in terms of the Debian bits and the systemd bits (discussed below). When upgrading the package on a machine will it stop the init service and start the Systemd service? There is no such thing as an "init service" on a systemd machine. If you have only /etc/init.d/foo, systemd is dynamically generating a foo.service unit. You can see this with e.g. "systemctl status foo". For example, on my system: $ systemctl status openipmi × openipmi.service - LSB: OpenIPMI Driver init script Loaded: loaded (/etc/init.d/openipmi; generated) When you install a foo.service unit file, that will take precedence over the generated one. So (assuming they have the same name), they are the same service. This package also stores its configuration in /var/lib/packagename and it should really be in /etc/packagename. Where is the best place to deal with auto-migration? Should this go in postinst or is there a debhelper that I should use? Take this with a grain of salt, and defer to more knowledgeable folks, but... If I were in that situation, I'd start with the idea of moving it in a preinst script. I would probably also guard it with version checks (as opposed to only checks for the existence of the folder). So something like (where the "2" in version-2~ is the package version one _higher_ than the version where you made the change, i.e. if you changed in -1, use -2~): #!/bin/sh set -e if [ "$1" = "upgrade" ] && [ -n "$2" ] then if dpkg --compare-versions "$2" le-nl "version-2~" then if [ -e /var/lib/packagename ] && ! [ -e /etc/packagename ] then mv /var/lib/packagename /etc/packagename fi fi fi That said, I'm not sure what Policy has to say about this. It seems to me that you want the package to do things right moving forward, and you want to support clean upgrades, so this seems like the approach that gets both of those. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Work-needing packages report for Apr 21, 2023
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1228 (new: 2) Total number of packages offered up for adoption: 159 (new: 0) Total number of packages requested help for: 58 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: gkermit (#1034447), orphaned 5 days ago Description: file transfer program Installations reported by Popcon: 210 Bug Report URL: https://bugs.debian.org/1034447 gpsd (#1034532), orphaned 3 days ago Description: Global Positioning System - daemon Reverse Depends: alfred direwolf foxtrotgps gpsd gpsd-clients gpsd-tools indi-gpsd libgps-dev libqgpsmm-dev marble-plugins (5 more omitted) Installations reported by Popcon: 17437 Bug Report URL: https://bugs.debian.org/1034532 1226 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 159 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1650 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web debian-edu-router-deployserver (125 more omitted) Installations reported by Popcon: 97730 Bug Report URL: https://bugs.debian.org/910917 apparmor (#1006872), requested 409 days ago Description: user-space parser utility for AppArmor Reverse Depends: apparmor-notify apparmor-profiles apparmor-profiles-extra apparmor-utils content-hub-testability dbus-broker dbus-daemon dbus-tests debian-cloud-images-packages dovecot-core (24 more omitted) Installations reported by Popcon: 193705 Bug Report URL: https://bugs.debian.org/1006872 autopkgtest (#846328), requested 2332 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1179 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 4225 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 593 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 2200 days ago Description: Rust package manager Reverse Depends: dh-cargo python3-setuptools-rust rust-all Installations reported by Popcon: 2896 Bug Report URL: https://bugs.debian.org/860116 chromium (#1016047), requested 268 days ago Description: web browser Reverse Depends: chromium chromium-driver chromium-l10n chromium-shell node-puppeteer qunit-selenium x2gothinclient-minidesktop Installations reported by Popcon: 24805 Bug Report URL: https://bugs.debian.org/1016047 courier (#978755), requested 840 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 748 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 774 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common bcron btrfsmaintenance buildd checksecurity clamtk cricket cron (25 more omitted) Installations reported by Popcon: 209612 Bug Report URL: https://bugs.debian.org/984736 cyrus-imapd (#921717), requested 1532 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 393 Bug Report URL: https://bugs.debian.org/921717 debtags (#962579), requested 1044 days ago Description: Debian Package Tags support tools Reverse Depends: packagesearch Installations reported by Popcon: 1356 Bug Report URL: https://bugs.debian.org/962579 dee (#831388), requested 2470 days ago Description: model to synchronize multiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0 libdee-dev libunity-dev libunity-protocol-private0 libunity-tools libunity9 zeitgeist-core In
