Conditionally enabling systemd files through Debian packaging
up vote
8
down vote
favorite
I've created a deb package which installs a service.
On our embedded devices, I want this package to automatically enable the service. On our developer workstations, I want the developers to systemctl start foo
manually (it's a heavy service, and so it just consumes resources if run all of the time on a desktop environment).
How can I go about prompting the user for their decision during the apt-get
step? Is that the best solution?
Note, I've created the package using dh_make
and debhelper
and enabled it with:
%:
dh $@ --with=systemd
override_dh_systemd_enable:
dh_systemd_enable --name=foo foo.service
systemd dpkg
add a comment |
up vote
8
down vote
favorite
I've created a deb package which installs a service.
On our embedded devices, I want this package to automatically enable the service. On our developer workstations, I want the developers to systemctl start foo
manually (it's a heavy service, and so it just consumes resources if run all of the time on a desktop environment).
How can I go about prompting the user for their decision during the apt-get
step? Is that the best solution?
Note, I've created the package using dh_make
and debhelper
and enabled it with:
%:
dh $@ --with=systemd
override_dh_systemd_enable:
dh_systemd_enable --name=foo foo.service
systemd dpkg
add a comment |
up vote
8
down vote
favorite
up vote
8
down vote
favorite
I've created a deb package which installs a service.
On our embedded devices, I want this package to automatically enable the service. On our developer workstations, I want the developers to systemctl start foo
manually (it's a heavy service, and so it just consumes resources if run all of the time on a desktop environment).
How can I go about prompting the user for their decision during the apt-get
step? Is that the best solution?
Note, I've created the package using dh_make
and debhelper
and enabled it with:
%:
dh $@ --with=systemd
override_dh_systemd_enable:
dh_systemd_enable --name=foo foo.service
systemd dpkg
I've created a deb package which installs a service.
On our embedded devices, I want this package to automatically enable the service. On our developer workstations, I want the developers to systemctl start foo
manually (it's a heavy service, and so it just consumes resources if run all of the time on a desktop environment).
How can I go about prompting the user for their decision during the apt-get
step? Is that the best solution?
Note, I've created the package using dh_make
and debhelper
and enabled it with:
%:
dh $@ --with=systemd
override_dh_systemd_enable:
dh_systemd_enable --name=foo foo.service
systemd dpkg
systemd dpkg
edited Dec 9 at 10:43
Peter Mortensen
86758
86758
asked Nov 12 at 9:49
Stewart
1798
1798
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
11
down vote
accepted
You can use systemd presets to affect whether a systemd service will default to being enabled or disabled at installation time.
The Debian presets default to enabling all services as they're installed, so you only need to ship a preset to the development workstations (the default behavior matches what you want to happen in production), by shipping a file such as /etc/systemd/system-preset/80-foo.preset
containing a line that says
disable foo.service
If you manage your developer workstations using a system such as Puppet, Chef, Ansible, etc., you can use them to ship such a systemd preset configuration, that should make it easy for you to apply the policy to developer workstations only and not production machines.
Your .deb package should use the systemctl preset
command to enable the service, since that command will respect the preset configuration.
As @JdeBP and @sourcejedi point out, the Debian macros in deb-helpers (such as dh_systemd_enable
) do that already, they invoke deb-systemd-helper
which will use systemctl preset
by default (with a small caveat that if you remove (but do not purge) the package, and later re-install it, it will then not enable the service, even if you remove the preset file.) See this comment in deb-systemd-helper
's enable
operation:
# We use 'systemctl preset' on the initial installation only.
# On upgrade, we manually add the missing symlinks only if the
# service already has some links installed. Using 'systemctl
# preset' allows administrators and downstreams to alter the
# enable policy using systemd-native tools.
For more information on the systemd feature of presets, see the man page of systemd presets and of the command systemctl preset
which implements it.
1
This is exactly what I needed. I deploy the dev environment through a meta-package and so I can install these*.preset
files as part of that package.
– Stewart
Nov 12 at 11:52
4
An important quirk to know is that presets are only consulted bydeb-systemd-helper
the first time that a package is installed. After that, the parallel database maintained by the Debian tools is consulted instead, until the package is purged. news.ycombinator.com/item?id=18320131
– JdeBP
Nov 12 at 11:53
1
Sodeb-systemd-helper
appears to use presets. And this should work without needing a manual systemctl preset command inside the .deb package. The Debian-specific quirk is what happens if you remove (but do not purge) the package. If you later re-install the package, it will then not enable the service, even if you remove the preset file. salsa.debian.org/debian/init-system-helpers/blob/debian/1.56/…
– sourcejedi
Nov 26 at 11:21
@sourcejedi Incorporated your comments and link to deb-systemd-helper comment into the answer. Thanks!
– Filipe Brandenburger
Nov 27 at 3:13
add a comment |
up vote
5
down vote
If you want to prompt the user during installation, you should use debconf
. This has a number of advantages, even if you’re not in a context where Debian Policy is relevant: it provides a consistent end-user experience, with support for a variety of frontends; it supports different “levels”; it supports pre-seeding. Pre-seeding means that the package can be pre-configured, in which case it won’t prompt at all. The different levels mean that a prompt can be set up to only show in certain circumstances; you could then have the package install without prompting by default (for your embedded targets), and instruct your developers to set up their frontend appropriately when installing the package so that they see the prompt.
However, I think it’s better to avoid prompting altogether when possible. This is especially true for services which have other ways of dealing with end-user preferences, and where dealing with user preferences complicates the maintainer scripts (see the generated scripts in your package, they already deal with a number of subtle issues, using deb-systemd-helper
— you’d have to replicate all that, with your preference handling on top).
If your developers never need to run the service, they can mask it before installing the package, and the service will never be enabled:
sudo systemctl mask foo
If your developers sometimes need to run the service, using the systemd unit, they can disable it after installing the package for the first time, and subsequent installs will remember this:
sudo apt install foo
sudo systemctl disable --now foo
The default would then be to enable the service.
Good answer.debconf
looks like what I had in mind, but I agree that it's best to avoid prompting when possible. I knew about thesystemctl disable
, but I was trying to help the user to avoid "skipping a step" during installation. The*.presets
solution suggested by Filippe solves this.
– Stewart
Nov 12 at 11:56
Indeed, presets fit the bill perfectly!
– Stephen Kitt
Nov 12 at 12:01
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f481228%2fconditionally-enabling-systemd-files-through-debian-packaging%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
accepted
You can use systemd presets to affect whether a systemd service will default to being enabled or disabled at installation time.
The Debian presets default to enabling all services as they're installed, so you only need to ship a preset to the development workstations (the default behavior matches what you want to happen in production), by shipping a file such as /etc/systemd/system-preset/80-foo.preset
containing a line that says
disable foo.service
If you manage your developer workstations using a system such as Puppet, Chef, Ansible, etc., you can use them to ship such a systemd preset configuration, that should make it easy for you to apply the policy to developer workstations only and not production machines.
Your .deb package should use the systemctl preset
command to enable the service, since that command will respect the preset configuration.
As @JdeBP and @sourcejedi point out, the Debian macros in deb-helpers (such as dh_systemd_enable
) do that already, they invoke deb-systemd-helper
which will use systemctl preset
by default (with a small caveat that if you remove (but do not purge) the package, and later re-install it, it will then not enable the service, even if you remove the preset file.) See this comment in deb-systemd-helper
's enable
operation:
# We use 'systemctl preset' on the initial installation only.
# On upgrade, we manually add the missing symlinks only if the
# service already has some links installed. Using 'systemctl
# preset' allows administrators and downstreams to alter the
# enable policy using systemd-native tools.
For more information on the systemd feature of presets, see the man page of systemd presets and of the command systemctl preset
which implements it.
1
This is exactly what I needed. I deploy the dev environment through a meta-package and so I can install these*.preset
files as part of that package.
– Stewart
Nov 12 at 11:52
4
An important quirk to know is that presets are only consulted bydeb-systemd-helper
the first time that a package is installed. After that, the parallel database maintained by the Debian tools is consulted instead, until the package is purged. news.ycombinator.com/item?id=18320131
– JdeBP
Nov 12 at 11:53
1
Sodeb-systemd-helper
appears to use presets. And this should work without needing a manual systemctl preset command inside the .deb package. The Debian-specific quirk is what happens if you remove (but do not purge) the package. If you later re-install the package, it will then not enable the service, even if you remove the preset file. salsa.debian.org/debian/init-system-helpers/blob/debian/1.56/…
– sourcejedi
Nov 26 at 11:21
@sourcejedi Incorporated your comments and link to deb-systemd-helper comment into the answer. Thanks!
– Filipe Brandenburger
Nov 27 at 3:13
add a comment |
up vote
11
down vote
accepted
You can use systemd presets to affect whether a systemd service will default to being enabled or disabled at installation time.
The Debian presets default to enabling all services as they're installed, so you only need to ship a preset to the development workstations (the default behavior matches what you want to happen in production), by shipping a file such as /etc/systemd/system-preset/80-foo.preset
containing a line that says
disable foo.service
If you manage your developer workstations using a system such as Puppet, Chef, Ansible, etc., you can use them to ship such a systemd preset configuration, that should make it easy for you to apply the policy to developer workstations only and not production machines.
Your .deb package should use the systemctl preset
command to enable the service, since that command will respect the preset configuration.
As @JdeBP and @sourcejedi point out, the Debian macros in deb-helpers (such as dh_systemd_enable
) do that already, they invoke deb-systemd-helper
which will use systemctl preset
by default (with a small caveat that if you remove (but do not purge) the package, and later re-install it, it will then not enable the service, even if you remove the preset file.) See this comment in deb-systemd-helper
's enable
operation:
# We use 'systemctl preset' on the initial installation only.
# On upgrade, we manually add the missing symlinks only if the
# service already has some links installed. Using 'systemctl
# preset' allows administrators and downstreams to alter the
# enable policy using systemd-native tools.
For more information on the systemd feature of presets, see the man page of systemd presets and of the command systemctl preset
which implements it.
1
This is exactly what I needed. I deploy the dev environment through a meta-package and so I can install these*.preset
files as part of that package.
– Stewart
Nov 12 at 11:52
4
An important quirk to know is that presets are only consulted bydeb-systemd-helper
the first time that a package is installed. After that, the parallel database maintained by the Debian tools is consulted instead, until the package is purged. news.ycombinator.com/item?id=18320131
– JdeBP
Nov 12 at 11:53
1
Sodeb-systemd-helper
appears to use presets. And this should work without needing a manual systemctl preset command inside the .deb package. The Debian-specific quirk is what happens if you remove (but do not purge) the package. If you later re-install the package, it will then not enable the service, even if you remove the preset file. salsa.debian.org/debian/init-system-helpers/blob/debian/1.56/…
– sourcejedi
Nov 26 at 11:21
@sourcejedi Incorporated your comments and link to deb-systemd-helper comment into the answer. Thanks!
– Filipe Brandenburger
Nov 27 at 3:13
add a comment |
up vote
11
down vote
accepted
up vote
11
down vote
accepted
You can use systemd presets to affect whether a systemd service will default to being enabled or disabled at installation time.
The Debian presets default to enabling all services as they're installed, so you only need to ship a preset to the development workstations (the default behavior matches what you want to happen in production), by shipping a file such as /etc/systemd/system-preset/80-foo.preset
containing a line that says
disable foo.service
If you manage your developer workstations using a system such as Puppet, Chef, Ansible, etc., you can use them to ship such a systemd preset configuration, that should make it easy for you to apply the policy to developer workstations only and not production machines.
Your .deb package should use the systemctl preset
command to enable the service, since that command will respect the preset configuration.
As @JdeBP and @sourcejedi point out, the Debian macros in deb-helpers (such as dh_systemd_enable
) do that already, they invoke deb-systemd-helper
which will use systemctl preset
by default (with a small caveat that if you remove (but do not purge) the package, and later re-install it, it will then not enable the service, even if you remove the preset file.) See this comment in deb-systemd-helper
's enable
operation:
# We use 'systemctl preset' on the initial installation only.
# On upgrade, we manually add the missing symlinks only if the
# service already has some links installed. Using 'systemctl
# preset' allows administrators and downstreams to alter the
# enable policy using systemd-native tools.
For more information on the systemd feature of presets, see the man page of systemd presets and of the command systemctl preset
which implements it.
You can use systemd presets to affect whether a systemd service will default to being enabled or disabled at installation time.
The Debian presets default to enabling all services as they're installed, so you only need to ship a preset to the development workstations (the default behavior matches what you want to happen in production), by shipping a file such as /etc/systemd/system-preset/80-foo.preset
containing a line that says
disable foo.service
If you manage your developer workstations using a system such as Puppet, Chef, Ansible, etc., you can use them to ship such a systemd preset configuration, that should make it easy for you to apply the policy to developer workstations only and not production machines.
Your .deb package should use the systemctl preset
command to enable the service, since that command will respect the preset configuration.
As @JdeBP and @sourcejedi point out, the Debian macros in deb-helpers (such as dh_systemd_enable
) do that already, they invoke deb-systemd-helper
which will use systemctl preset
by default (with a small caveat that if you remove (but do not purge) the package, and later re-install it, it will then not enable the service, even if you remove the preset file.) See this comment in deb-systemd-helper
's enable
operation:
# We use 'systemctl preset' on the initial installation only.
# On upgrade, we manually add the missing symlinks only if the
# service already has some links installed. Using 'systemctl
# preset' allows administrators and downstreams to alter the
# enable policy using systemd-native tools.
For more information on the systemd feature of presets, see the man page of systemd presets and of the command systemctl preset
which implements it.
edited Nov 27 at 3:13
answered Nov 12 at 11:24
Filipe Brandenburger
6,8552733
6,8552733
1
This is exactly what I needed. I deploy the dev environment through a meta-package and so I can install these*.preset
files as part of that package.
– Stewart
Nov 12 at 11:52
4
An important quirk to know is that presets are only consulted bydeb-systemd-helper
the first time that a package is installed. After that, the parallel database maintained by the Debian tools is consulted instead, until the package is purged. news.ycombinator.com/item?id=18320131
– JdeBP
Nov 12 at 11:53
1
Sodeb-systemd-helper
appears to use presets. And this should work without needing a manual systemctl preset command inside the .deb package. The Debian-specific quirk is what happens if you remove (but do not purge) the package. If you later re-install the package, it will then not enable the service, even if you remove the preset file. salsa.debian.org/debian/init-system-helpers/blob/debian/1.56/…
– sourcejedi
Nov 26 at 11:21
@sourcejedi Incorporated your comments and link to deb-systemd-helper comment into the answer. Thanks!
– Filipe Brandenburger
Nov 27 at 3:13
add a comment |
1
This is exactly what I needed. I deploy the dev environment through a meta-package and so I can install these*.preset
files as part of that package.
– Stewart
Nov 12 at 11:52
4
An important quirk to know is that presets are only consulted bydeb-systemd-helper
the first time that a package is installed. After that, the parallel database maintained by the Debian tools is consulted instead, until the package is purged. news.ycombinator.com/item?id=18320131
– JdeBP
Nov 12 at 11:53
1
Sodeb-systemd-helper
appears to use presets. And this should work without needing a manual systemctl preset command inside the .deb package. The Debian-specific quirk is what happens if you remove (but do not purge) the package. If you later re-install the package, it will then not enable the service, even if you remove the preset file. salsa.debian.org/debian/init-system-helpers/blob/debian/1.56/…
– sourcejedi
Nov 26 at 11:21
@sourcejedi Incorporated your comments and link to deb-systemd-helper comment into the answer. Thanks!
– Filipe Brandenburger
Nov 27 at 3:13
1
1
This is exactly what I needed. I deploy the dev environment through a meta-package and so I can install these
*.preset
files as part of that package.– Stewart
Nov 12 at 11:52
This is exactly what I needed. I deploy the dev environment through a meta-package and so I can install these
*.preset
files as part of that package.– Stewart
Nov 12 at 11:52
4
4
An important quirk to know is that presets are only consulted by
deb-systemd-helper
the first time that a package is installed. After that, the parallel database maintained by the Debian tools is consulted instead, until the package is purged. news.ycombinator.com/item?id=18320131– JdeBP
Nov 12 at 11:53
An important quirk to know is that presets are only consulted by
deb-systemd-helper
the first time that a package is installed. After that, the parallel database maintained by the Debian tools is consulted instead, until the package is purged. news.ycombinator.com/item?id=18320131– JdeBP
Nov 12 at 11:53
1
1
So
deb-systemd-helper
appears to use presets. And this should work without needing a manual systemctl preset command inside the .deb package. The Debian-specific quirk is what happens if you remove (but do not purge) the package. If you later re-install the package, it will then not enable the service, even if you remove the preset file. salsa.debian.org/debian/init-system-helpers/blob/debian/1.56/…– sourcejedi
Nov 26 at 11:21
So
deb-systemd-helper
appears to use presets. And this should work without needing a manual systemctl preset command inside the .deb package. The Debian-specific quirk is what happens if you remove (but do not purge) the package. If you later re-install the package, it will then not enable the service, even if you remove the preset file. salsa.debian.org/debian/init-system-helpers/blob/debian/1.56/…– sourcejedi
Nov 26 at 11:21
@sourcejedi Incorporated your comments and link to deb-systemd-helper comment into the answer. Thanks!
– Filipe Brandenburger
Nov 27 at 3:13
@sourcejedi Incorporated your comments and link to deb-systemd-helper comment into the answer. Thanks!
– Filipe Brandenburger
Nov 27 at 3:13
add a comment |
up vote
5
down vote
If you want to prompt the user during installation, you should use debconf
. This has a number of advantages, even if you’re not in a context where Debian Policy is relevant: it provides a consistent end-user experience, with support for a variety of frontends; it supports different “levels”; it supports pre-seeding. Pre-seeding means that the package can be pre-configured, in which case it won’t prompt at all. The different levels mean that a prompt can be set up to only show in certain circumstances; you could then have the package install without prompting by default (for your embedded targets), and instruct your developers to set up their frontend appropriately when installing the package so that they see the prompt.
However, I think it’s better to avoid prompting altogether when possible. This is especially true for services which have other ways of dealing with end-user preferences, and where dealing with user preferences complicates the maintainer scripts (see the generated scripts in your package, they already deal with a number of subtle issues, using deb-systemd-helper
— you’d have to replicate all that, with your preference handling on top).
If your developers never need to run the service, they can mask it before installing the package, and the service will never be enabled:
sudo systemctl mask foo
If your developers sometimes need to run the service, using the systemd unit, they can disable it after installing the package for the first time, and subsequent installs will remember this:
sudo apt install foo
sudo systemctl disable --now foo
The default would then be to enable the service.
Good answer.debconf
looks like what I had in mind, but I agree that it's best to avoid prompting when possible. I knew about thesystemctl disable
, but I was trying to help the user to avoid "skipping a step" during installation. The*.presets
solution suggested by Filippe solves this.
– Stewart
Nov 12 at 11:56
Indeed, presets fit the bill perfectly!
– Stephen Kitt
Nov 12 at 12:01
add a comment |
up vote
5
down vote
If you want to prompt the user during installation, you should use debconf
. This has a number of advantages, even if you’re not in a context where Debian Policy is relevant: it provides a consistent end-user experience, with support for a variety of frontends; it supports different “levels”; it supports pre-seeding. Pre-seeding means that the package can be pre-configured, in which case it won’t prompt at all. The different levels mean that a prompt can be set up to only show in certain circumstances; you could then have the package install without prompting by default (for your embedded targets), and instruct your developers to set up their frontend appropriately when installing the package so that they see the prompt.
However, I think it’s better to avoid prompting altogether when possible. This is especially true for services which have other ways of dealing with end-user preferences, and where dealing with user preferences complicates the maintainer scripts (see the generated scripts in your package, they already deal with a number of subtle issues, using deb-systemd-helper
— you’d have to replicate all that, with your preference handling on top).
If your developers never need to run the service, they can mask it before installing the package, and the service will never be enabled:
sudo systemctl mask foo
If your developers sometimes need to run the service, using the systemd unit, they can disable it after installing the package for the first time, and subsequent installs will remember this:
sudo apt install foo
sudo systemctl disable --now foo
The default would then be to enable the service.
Good answer.debconf
looks like what I had in mind, but I agree that it's best to avoid prompting when possible. I knew about thesystemctl disable
, but I was trying to help the user to avoid "skipping a step" during installation. The*.presets
solution suggested by Filippe solves this.
– Stewart
Nov 12 at 11:56
Indeed, presets fit the bill perfectly!
– Stephen Kitt
Nov 12 at 12:01
add a comment |
up vote
5
down vote
up vote
5
down vote
If you want to prompt the user during installation, you should use debconf
. This has a number of advantages, even if you’re not in a context where Debian Policy is relevant: it provides a consistent end-user experience, with support for a variety of frontends; it supports different “levels”; it supports pre-seeding. Pre-seeding means that the package can be pre-configured, in which case it won’t prompt at all. The different levels mean that a prompt can be set up to only show in certain circumstances; you could then have the package install without prompting by default (for your embedded targets), and instruct your developers to set up their frontend appropriately when installing the package so that they see the prompt.
However, I think it’s better to avoid prompting altogether when possible. This is especially true for services which have other ways of dealing with end-user preferences, and where dealing with user preferences complicates the maintainer scripts (see the generated scripts in your package, they already deal with a number of subtle issues, using deb-systemd-helper
— you’d have to replicate all that, with your preference handling on top).
If your developers never need to run the service, they can mask it before installing the package, and the service will never be enabled:
sudo systemctl mask foo
If your developers sometimes need to run the service, using the systemd unit, they can disable it after installing the package for the first time, and subsequent installs will remember this:
sudo apt install foo
sudo systemctl disable --now foo
The default would then be to enable the service.
If you want to prompt the user during installation, you should use debconf
. This has a number of advantages, even if you’re not in a context where Debian Policy is relevant: it provides a consistent end-user experience, with support for a variety of frontends; it supports different “levels”; it supports pre-seeding. Pre-seeding means that the package can be pre-configured, in which case it won’t prompt at all. The different levels mean that a prompt can be set up to only show in certain circumstances; you could then have the package install without prompting by default (for your embedded targets), and instruct your developers to set up their frontend appropriately when installing the package so that they see the prompt.
However, I think it’s better to avoid prompting altogether when possible. This is especially true for services which have other ways of dealing with end-user preferences, and where dealing with user preferences complicates the maintainer scripts (see the generated scripts in your package, they already deal with a number of subtle issues, using deb-systemd-helper
— you’d have to replicate all that, with your preference handling on top).
If your developers never need to run the service, they can mask it before installing the package, and the service will never be enabled:
sudo systemctl mask foo
If your developers sometimes need to run the service, using the systemd unit, they can disable it after installing the package for the first time, and subsequent installs will remember this:
sudo apt install foo
sudo systemctl disable --now foo
The default would then be to enable the service.
answered Nov 12 at 10:57
Stephen Kitt
162k24358436
162k24358436
Good answer.debconf
looks like what I had in mind, but I agree that it's best to avoid prompting when possible. I knew about thesystemctl disable
, but I was trying to help the user to avoid "skipping a step" during installation. The*.presets
solution suggested by Filippe solves this.
– Stewart
Nov 12 at 11:56
Indeed, presets fit the bill perfectly!
– Stephen Kitt
Nov 12 at 12:01
add a comment |
Good answer.debconf
looks like what I had in mind, but I agree that it's best to avoid prompting when possible. I knew about thesystemctl disable
, but I was trying to help the user to avoid "skipping a step" during installation. The*.presets
solution suggested by Filippe solves this.
– Stewart
Nov 12 at 11:56
Indeed, presets fit the bill perfectly!
– Stephen Kitt
Nov 12 at 12:01
Good answer.
debconf
looks like what I had in mind, but I agree that it's best to avoid prompting when possible. I knew about the systemctl disable
, but I was trying to help the user to avoid "skipping a step" during installation. The *.presets
solution suggested by Filippe solves this.– Stewart
Nov 12 at 11:56
Good answer.
debconf
looks like what I had in mind, but I agree that it's best to avoid prompting when possible. I knew about the systemctl disable
, but I was trying to help the user to avoid "skipping a step" during installation. The *.presets
solution suggested by Filippe solves this.– Stewart
Nov 12 at 11:56
Indeed, presets fit the bill perfectly!
– Stephen Kitt
Nov 12 at 12:01
Indeed, presets fit the bill perfectly!
– Stephen Kitt
Nov 12 at 12:01
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f481228%2fconditionally-enabling-systemd-files-through-debian-packaging%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown