-----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(a)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(a)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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlOxvY0ACgkQeiVVYja6o6MatQCfTkVujhA7u5zZMt2wqdx5+yVF
B48AnRZqvjs1ib+NdDH2ZLFt99A4U+9S
=FCeY
-----END PGP SIGNATURE-----