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. So what is the motivation behind this? To prevent someone from just installing fedora-release-$PRODUCT and claiming they have $PRODUCT installed? >>> 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. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
