fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
jwboyer at fedoraproject.org
Mon Jun 30 19:38:30 UTC 2014
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
> 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
> 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.
So what is the motivation behind this? To prevent someone from just
installing fedora-release-$PRODUCT and claiming they have $PRODUCT
>>> 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
>>> 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.
More information about the devel