Re: Systemd Preset Policy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2015-07-26 at 15:23 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Jul 26, 2015 at 08:05:08AM -0400, Nico Kadel-Garcia wrote:
> > On Sat, Jul 25, 2015 at 8:28 PM, Zbigniew Jędrzejewski-Szmek
> > <zbyszek@xxxxxxxxx> wrote:
> > > On Sat, Jul 25, 2015 at 06:06:42PM -0600, Kevin Fenzi wrote:
> > > > On Sat, 25 Jul 2015 23:56:07 +0000
> > > > Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:
> > > > 
> > > > > On Sat, Jul 25, 2015 at 10:41:55PM +0100, Sérgio Basto wrote:
> > > > > > The packages that I'm concerned about are in a third party 
> > > > > > repo .
> > > > > > How we may workaround this ? is to add one file
> > > > > > in /usr/lib/systemd/system-preset/ ?
> > > > > Yes, that's one option. I think that it's fairly reasoanble 
> > > > > in case
> > > > > of a third-party low-level service like vboxservice.service.
> > > > 
> > > > I would think the third party might ship their own presets in 
> > > > their
> > > > release package or the like?
> > > In the release package or even in the package containing the 
> > > service
> > > itself. That's the way I understood what Sérgio wrote.
> > > 
> > > (Either way, the preset file can be easily overriden by the
> > > administartor by adding a file with the same name in /etc,
> > > or by including a file with sorts earlier.)
> > > 
> > > Zbyszek
> > 
> > It is the sort of eleventh hour re-arrangement of existing defaults
> > that make people very, very leery of anything involving systemd. 
> > The
> > change may well be worth doing, but "oh, you can just go fix that
> > yourself with a workaround" accumulates into a lot of work very
> > quickly, and it makes 3rd party integration for multiple platforms
> > that extra bit more difficult.
> 11th hour — in what timezone? ;) There's nothing urgent about this at
> all. Let me reiterate: Fedora decided that Fedora packages will use
> this mechanism to decide which services are enabled by default.
> The old mechanism where the package hardcodes that setting still
> works, will continue to work, and is available to any package.
> 
> Maybe it wasn't clear from the discussion above: for external 
> packages
> which can only be installed explicitly (not through dependencies)
> always starting the service on installation is reasonable. So
> they *can* add preset support, but don't *have* to.
> 


Right, the FESCo decision was intended to solve three problems (which
%post scriptlets cannot do easily)

1) FESCo has always been the arbiter of what packages are allowed to
start services by default on the system; Make that easier to implement
rather than requiring packagers to put specific code into their spec
files. Now all the logic for this lives in a preset file contained in
the fedora-release package
2) Allow the list of services started by default to be different
depending on the Edition of Fedora (for example, Workstation wants to
default to not running OpenSSH by default). By managing the preset drop
-ins in the fedora-release-$EDITION packages, this is possible.
3) Manage the presets at the distribution level rather than in the
systemd package; prior to this change, the default presets were
shipping in the systemd package itself, which meant that FESCo needed
to coordinate with the systemd maintainer (and make a release of the
systemd package) to change the presets. Now it's part of the fedora
-release package which is smaller and easier for us to manage.

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux