On Wed, Jun 18, 2014 at 3:15 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
We talked about this before, but I think now it's getting really
close to
the time when we _need_ it. See
<
https://bugzilla.redhat.com/show_bug.cgi?id=1110764>... as Dennis says, we
have not yet decided how to differentiate the different Fedora products.
I suggest that we have fedora-release-{workstation,server,cloud} packages. I
had originally suggested these as subpackages of fedora-release, but I think
that it might actually be better to have them be separate packages, so they
can be maintained and released individually.
Separate packages please, we want to keep the thrash/churn on a
release packages low.
These packages could have dependencies on other packages which are essential
to that product's identity (like ye olde dreaded "redhat-lsb", I suppose),
and could either contain systemd presets appropriate for that product -- or
perhaps better, could depend on another (for example) fedora-presets-server
package.
Same as above, keep the systemd preset files out of the release
package, but feel free to add whatever requirements make sense.
Aslo, each workgroup should be able to set what services are started
in
those presets rather than needing a FESCo exception (because that's part of
the point of the different WGs, after all).
Right now, all of the packages are drawing from the same repos, but this
would also provide an avenue for doing that differently in the future if we
so choose.
I also suggest that /etc/os-release be switched using the alternatives
system (
http://fedoraproject.org/wiki/Packaging:Alternatives), with the
variant in either the VERSION field (VERSION="21 (Cloud)") or a new
os-release field which we would propose -- probably VARIANT.
I suppose it's better than making server, workstation or whatever
mutually exclusive.
Would /etc/os-release --> /etc/os-release-{workstation,server,cloud}
I suppose /etc/issue and /etc/issue.net would also be candidates for
alternatives.
Perhaps, but /etc/issue.* files are things the sysadmin should be
managing, so IMHO be left alone.
(Perhaps I'm not fully appreciating the implications)
--
-Jon Disnard