[PATCHES] os-release: Populate VARIANT and VARIANT_ID values

[Dennis Gilmore]

On Friday, May 08, 2015 11:13:19 AM Stephen Gallagher wrote:
> ----- Original Message -----
> 
> > From: "Matthew Miller" <mattdm at fedoraproject.org>
> > To: "Stephen Gallagher" <sgallagh at redhat.com>
> > Cc: "Kalev Lember" <kalevlember at gmail.com>,
> > rel-eng at lists.fedoraproject.org
> > Sent: Friday, May 8, 2015 10:30:28 AM
> > Subject: Re: [PATCHES] os-release: Populate VARIANT and VARIANT_ID values
> > 
> > On Fri, May 08, 2015 at 09:55:59AM -0400, Stephen Gallagher wrote:
> > > We could easily do this as well, if that was desired, but that should
> > > be a separate change. I'd slightly prefer to do that in Rawhide for
> > > F23 and not on F22, just on the off-chance that anyone is actually
> > > doing anything with PRETTY_NAME, which has been a standard value for
> > > a long time.
> > 
> > Agree with in Rawhide. What about:
> > 
> > * change VERSION to just "23",
> > * PRETTY_NAME to "Fedora $VERSION"
> > 
> > and update places which use $PRETTY_NAME to use "$PRETTY NAME
> > ($VARIANT)" instead if appropriate? (Because in some cases the
> > non-specific pretty name might be more appropriate.)
> 
> For the record, while /etc/os-release is meant to be source-able into a
> Bourne-compatible shell, it's at the very least frowned upon for it to have
> any variable substitutions in it. So let's please not do that.
> 
> That being said, the way we actually create this file is by complete
> substitution of the file, not by constructing it from component pieces.
> Each fedora-release-$EDITION package drops a file called
> os-release-$EDITION into place on the system and then symlinks it to
> /usr/lib/os-release if no symlink currently exists (which is how we can
> avoid collisions if someone installs fedora-release-workstation on a Fedora
> Server; it will just not do anything).
> > I guess PRETTY_NAME="Fedora $VERSION ($VARIANT)" would also be okay,
> > but I'm imagining there might be some cases where having it separate
> > might be useful. (Maybe not.)
> 
> If we chose to do something like this, it should use literal values, not the
> substitutions (It was unclear if that was what you were saying).
> 
> So
> PRETTY_NAME="Fedora 23 (Server Edition)"
I have implemented this in rawhide. the productised versions will show the 
edition installed. while non productised versions will have Rawhide, Twenty 
Three, etc


> > Also, Stephen, a question — should spins set VARIANT and VARIENT_ID?
> 
> That's a question with more to it than you might think. Based on the way
> we're creating the os-release file, if a spin wanted to have a different
> VARIANT and VARIANT_ID, it would need to ship a spin-specific
> fedora-release-$SPIN package containing this os-release file.
I would rather not do so as it would lead to a bunch more fedora-release-foo 
packages, I think the variants shuold be limited to products and not spins.  
to me it is part of the differentiation.

> The only reason to have VARIANTs defined here are for divergent
> configuration defaults, which we've previously asserted is only permissible
> with WG or FESCo permission, which is less likely for most spins. (I could
> see some of the more well-maintained spins like KDE possibly making such a
> request).
> 
> I'd say that spins should not set this value unless they have been granted
> permission by FESCo and at that point we should extend the fedora-release
> package to produce a fedora-release-$SPIN subpackage for them that handles
> this. I don't want us handing out permission to generate os-release
> willy-nilly or it devalues os-release.
> _______________________________________________
> rel-eng mailing list
> rel-eng at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/rel-eng
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20150508/f8730a8d/attachment.sig>