[PATCH] Generate os-release from component parts

Stephen Gallagher sgallagh at redhat.com
Wed Mar 11 16:33:59 UTC 2015


On Wed, 2015-03-11 at 11:19 -0500, Dennis Gilmore wrote:
> > > 
...
> On Wednesday, March 11, 2015 06:31:58 AM Stephen Gallagher wrote:
> > > I am not opposed to doing something, but I am not sure this is 
> > > right. there is some builds that need /etc/os-release to be 
> > > present and setup to
> > > build.
> > Dennis, can you get me some specific examples I can look at and 
> > account for?
> > Also see below for why this may not be an issue.
> https://fedorahosted.org/rel-eng/ticket/6097
> this was a issue hit recently because mock was breaking things
> 
> > > I
> > > think that systemd itself needs /usr/lib/os-release and/or 
> > > /etc/os-release
> > > to be present to actually boot the system.
> > 
> > Zbigniew, is this accurate? Does systemd need this file on the 
> > disk to boot?
> > 
> > In any case, I think this may not be an issue in the current 
> > approach, as
> > I'm generating the file at package install time as well at each 
> > boot, so the previous boot's os-release file will be there.
> At the least we need to keep /usr/lib/os-release and I think it 
> being the 
> generic non productised version. you removed it entirely 
> 


OK, you guys make good points. Dennis, Peter: does Zbigniew's approach 
look sensible to you? I think it mostly works for me.

I was mainly trying in my approach to make the solution more generic, 
in case Spins also wanted to amend the os-release results, but I'm 
okay if we want to take the stance that os-release is limited to 
Editions and that all spins just use the non-Edition approaches.

One thing to note: part of the intent here is to be able to to also 
remove the Conflicts: between the fedora-release-$edition subpackages, 
but only have the first one installed take effect. (This is mostly to 
resolve the post-install yum/dnf issues where attempting to install an 
environment group tries to pull in a conflicting release package). It 
could make things look a little odd if one removed the first release 
package after installing another one, but I think a strong argument 
could be made at that point that having no VARIANT is the correct 
answer, since the resulting system is definitely not consistent with 
an existing Edition.

Anyway, if this approach seems sensible to everyone here, I'll happily 
retool the patch.
-------------- 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/648938d8/attachment.sig>


More information about the rel-eng mailing list