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@xxxxxxxxx> wrote: > > > On Wed, Jun 18, 2014 at 3:15 PM, Matthew Miller > > <mattdm@xxxxxxxxxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
