fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

Mon Jun 30 19:42:06 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/30/2014 03:38 PM, Josh Boyer wrote:
> On Mon, Jun 30, 2014 at 3:30 PM, Stephen Gallagher
> <sgallagh at redhat.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 06/30/2014 03:08 PM, Josh Boyer wrote:
>>> On Mon, Jun 30, 2014 at 2:59 PM, Stephen Gallagher 
>>> <sgallagh at redhat.com> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>> 
>>>> We're getting down to the wire on Fedora 21 and we need to
>>>> nail down a few of the low-level release requirements.
>>>> 
>>>> First of all, I'd like to formally propose that each of the 
>>>> products will have a fedora-release-$PRODUCT (and
>>>> corresponding generic-release-$PRODUCT) package. This package
>>>> will meet several needs (with magical hand-waving in this
>>>> initial email).
>>>> 
>>>> 1) All Products will add explicit Requires: to the 
>>>> fedora-release-$PRODUCT package so that they may define
>>>> their minimal operating set properly. The presence or absence
>>>> of this package on the system will indicate definitively
>>>> which Product (if any) is operating here.
>>> 
>>> Um... add Requires: where?  Do you mean "All Products will 
>>> explicitly
>> 
>> There will be Requires: as part of of the
>> fedora-release-$PRODUCT package itself, therefore guaranteeing
>> that a certain set of packages are always installed if the
>> fedora-release-$PRODUCT package is.
>> 
>> 
>>> include the fedora-release-$PRODUCT package in their kickstart 
>>> files"? The way you have it phrased now seems to imply that
>>> some other package Requires: fedora-release-$PRODUCT which
>>> seems very odd.
>>> 
>> 
>> Let me give an example of the definition of
>> fedora-release-server.
>> 
>> Name: fedora-release-server Version: 21 Release: 1 Requires:
>> cockpit Requires: rolekit
> 
> OK, I misread.  Though looking at this, I'm not sure it's really
> the best solution here.  It would certainly work, but it seems
> cumbersome if your product requires more than a handful of
> packages.  Listing them all out would be superfluous since comps
> should already do this. Relying on an explicitly listed handful to
> bring in the rest via their RPM deps seems fragile.  What you have
> may work for Server but I'm skeptical it will be feasible for
> Workstation.
> 

I'd *LOVE* for yum/dnf to be able to have Requires: @yum-group,
personally...

> So what is the motivation behind this?  To prevent someone from
> just installing fedora-release-$PRODUCT and claiming they have
> $PRODUCT installed?
> 

That's a piece of it, but it's also meant for there to be a strong
mechanism for ensuring that all the right pieces are in place to call
it $PRODUCT. We really want to be curating these products very
carefully. Doing it this way makes it certain that the Product has all
the pieces we expect it to.

>>>> 2) The fedora-release-$PRODUCT package (and possibly %post
>>>> or systemd snippets therein) will be responsible for the
>>>> creation and maintenance of /etc/issue, /etc/os-release and 
>>>> /etc/fedora-release-product (note: there is no $ there.
>>>> That's the literal name. This file will be equivalent to 
>>>> /etc/fedora-release except that it will include the Product 
>>>> name.
>>>> 
>>>> 3) fedora-release-$PRODUCT will have an explicit Conflict
>>>> with all other fedora-release-$PRODUCT packages, to ensure
>>>> that we do not mix-and-match (which is a combinatorial
>>>> nightmare).
>>> 
>>> How does this play into the pets vs. cattle thing that Server
>>> and Cloud have talked about?  How would one go from a cattle
>>> Cloud instance to a pet Server instance in the Cloud if there
>>> are explicit conflicts there.
>> 
>> This is going to require an explicit migration tool. I'm still
>> trying to figure out the details on this with Matthew. Given the
>> late hour (F21 Alpha is coming up on us fast), I might recommend
>> deferring "Adopt-Your-Cattle" to F22, but we'll see how that
>> goes.
> 
> OK.  FWIW, I never thought that scenario made sense to begin with 
> anyway.  There's really no difference to the specific instance
> other than how it is managed and if someone wanted to claim Server
> status they could just create a dedicated Server VM.

Also fair points.