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

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Sat Jun 21 00:19:35 UTC 2014


On Wed, Jun 18, 2014 at 04:55:02PM -0500, Jon wrote:
> > 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.
Yes, either should work.

> I suppose it's better than making server, workstation or whatever
> mutually exclusive.
> Would /etc/os-release --> /etc/os-release-{workstation,server,cloud}
The whole point of moving to /etc/os-release is that (on any distro)
it is trivial to query because of the fixed filename. Renaming is
not really an option.

On Wed, Jun 18, 2014 at 07:11:56PM -0500, Dennis Gilmore wrote:
> On Wed, 18 Jun 2014 16:55:02 -0500
> Jon <jdisnard at gmail.com> wrote:
> 
> > On Wed, Jun 18, 2014 at 3:15 PM, Matthew Miller
> > <mattdm at 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.
> 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.
I think this shows that the idea of allowing multiple
fedora-release-<variant> packages to be installed is going
to drive people crazy. Even a simple question which set of
presets is active will not be easy to answer. I think that installing
packages from multiple products should be fine in general, but
the branding and defaults should be exclusive.

> > > 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}
> eww, I honestly don't think alternatives is appropriate here.
Yeah, let's not overcomplicate things.

> > > 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)

Zbyszek


More information about the devel mailing list