[PATCH] Generate os-release from component parts

[Stephen Gallagher]

On Wed, 2015-03-11 at 11:52 -0400, Colin Walters wrote:
> On Wed, Mar 11, 2015, at 08:59 AM, Stephen Gallagher wrote:
> > 
> > 1) Be able to install Fedora Server and then 'dnf install "Fedora  
> > Workstation"' which will result in all the Workstation *packages*  
> > being on the system, but have it still be Server where divergent  
> > defaults are concerned. 
> 
> A few things:
>  - Cockpit was created with a major goal of reducing the need for 
> "Server with GUI"
 - Would that still be the Server product?  What about fedora-
release-server-with-gui?

We don't want a Server-with-GUI product. The Server WG talked about it 
and decided that firmly.

This is mostly about addressing the cases where an end-user really 
needs such a thing (like third-party apps that can only be installed 
with a GUI). So we have to be able to install a graphical environment 
atop the Server environment.

It doesn't make it Fedora Workstation, it makes it Fedora Server with 
packages that also happen to be on Fedora Workstation (a subtle but 
important distinction; any package installed this way that differs 
between Workstation and Server in its configuration will end up with 
the Fedora Server version. Period.)



>  - There was some talk of comps group inheritance at some point, if 
> that happened,
>    there could be fedora-workstation-product-packages which 
> contained everything
>    but the -release or so.

The problem here is actually with displaying the groups in dnf on the 
installed system; all environment groups are displayed, which would 
include the -release. If we can make them parallel-installable *but* 
only one is "active", that would eliminate the conflict problem.


>  - Also worth noting a goal for the rpm-ostree effort is to 
> represent the "base"
>    of a system as a branch, e.g.:
>    fedora/f23/x86_64/server
>    fedora/f23/x86_64/server-with-gui
>    fedora/f23/x86_64/workstation
>    Then you can atomically rebase between them, and "rpm-ostree 
> status" provides
>    a description of your base system.
> 

I don't actually see the relevance here. Maybe I'm missing it.


> > 2) Eliminate the foo-config-$PRODUCT subpackages providing per-
> > product  configuration. These were designed around fairly esoteric 
> > knowledge of  the yum dependency solver which resulted in the 
> > "right" version of  this subpackage being pulled in if the 
> > associated fedora-release- $PRODUCT package happened to be 
> > installed. This fell apart when we  switched to DNF in some places.
> 
> I don't know much about the foo-config packages.
> 

Avoid learning about it. It's quicksand filled with snakes.


> > 3) Have /etc/os-release be the definitive place to look up which  
> > Edition (if any) of Fedora is installed on this machine.
> 
> Right.  I'm just dubious about attempting to generate this 
> dynamically.

Well, "dynamically" is kind of a loose term here. It's really just a 
mechanism that when certain packages are installed, the end result 
should end up as /etc/os-release. The only reason I have it done 
"dynamically" in a service unit is because I'm trying to maintain the 
eventual goal of an empty /etc at boot. That (as I understand it) was 
the reason for moving to the /usr/lib symlink in the first place, 
since the "API" for os-release requires /etc/os-release but it's not 
really dynamic user content.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20150311/8e1fb4bb/attachment.sig>