-----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@xxxxxxxxxx> 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@xxxxxxxxxx> 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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
