On Thu, 03.07.14 19:11, Tom Lane (tgl@xxxxxxxxxxxxx) wrote:
>
> Lennart Poettering <mzerqung@xxxxxxxxxxx> writes:
> > Please migrate away from ".include", please use .d/ drop-ins instead. We
> > kinda are deprecating ".include", only support it for compatibility
> > instead. ...
> > Unit files are configuration files. It's OK to copy unit files from
> > /usr/lib/systemd/system into /etc/systemd/system and edit it there.
>
> FWIW, I don't think that's OK at all, and that's what I tried to avoid in
> the original layout for Postgres' systemd files. If people create the
> files for secondary postmasters by cloning the entire unit file, then
> there is no way for us to push out fixes in the unit file; or at least
> none that doesn't break secondary servers.
>
> If unit files tended to be trivial two-line affairs, this concern might
> not have much force, but they're generally not. Certainly the Postgres
> one isn't.
Link?
Are you sure that you didn't make them this complex because you wanted
to not simply allow people to copy them?
>
> So I think deprecation of ".include" is *seriously* misguided. We really
> need a way to create secondary-server unit files that don't contain
> anything more than alternate PGPORT and PGDATA settings plus an inclusion
> of a master unit file. (I'll grant that there might be other ways to
> mechanize such a behavior, but if you're telling me I don't need this,
> you're mistaken, sir.)
Well, the .include stuff is awful, since it's incredible hard to figure
out when they are out of date, and whether there are loops in the
include chain. The .d/ drop-ins don't suffer by the problem.
Also note that we do provide template units, for the cases where people
want to run multiple instances. You can even mix .d and template units:
postgresql@foobar.service
postgresql@foobar.service/addition.conf
postgresql@waldo.service
postgresql@waldo.service/extension.conf
And so on...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
