Proposal: time to set up the fedora-release-{cloud, workstation, server} subpackages

Dennis Gilmore dennis at
Thu Jun 19 00:11:56 UTC 2014

Hash: SHA1

On Wed, 18 Jun 2014 16:55:02 -0500
Jon <jdisnard at> wrote:

> On Wed, Jun 18, 2014 at 3:15 PM, Matthew Miller
> <mattdm at> wrote:
> > We talked about this before, but I think now it's getting really
> > close to the time when we _need_ it. See
> > <>... 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.
I actually prefer a single package. if its not we will at the least
need to look at making a separate repos packages. as thats something we
do not want to risk copy paste errors etc.

> >
> > 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
> > (, 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}
eww, I honestly don't think alternatives is appropriate here.

> > I suppose /etc/issue and /etc/ 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)

Version: GnuPG v2.0.22 (GNU/Linux)


More information about the devel mailing list