-----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.
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).
Additionally, I am working on a proposal[1] for per-product configs in the Fedora 21 timeframe which is dependent on the above. It should be noted that this is an interim solution only; in Fedora 22 we will be able to vastly simplify this situation with the weak dependency support in RPM 4.12. (I was looking for a link detailing all of these weak deps, but I cannot find one. If you know of such a document, please reply and add it).
[1] https://fedoraproject.org/wiki/Per-Product_Configuration_Packaging_Draft
On Mon, Jun 30, 2014 at 2:59 PM, Stephen Gallagher sgallagh@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).
- 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 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.
- 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.
- 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.
josh
-----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@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).
- 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
- 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.
- 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.
On Mon, Jun 30, 2014 at 3:30 PM, Stephen Gallagher sgallagh@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@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).
- 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?
- 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.
- 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
-----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@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@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).
- 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.
- 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.
- 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.
On Mon, 2014-06-30 at 15:42 -0400, Stephen Gallagher wrote:
On 06/30/2014 03:38 PM, Josh Boyer wrote:
On Mon, Jun 30, 2014 at 3:30 PM, Stephen Gallagher sgallagh@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@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).
- 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...
The problem here is that the meaning of @yum-group changes depending on what repos. you have installed (and other things). And having dynamic deps. is really bad. You could maybe do something at rpmbuild time which would convert @yum-group into the a list of packages, just to make the spec files nicer (but this will then be one more magic thing that changes depending on how/where/when you built the .src.rpm).
On Mon, 30.06.14 14:59, Stephen Gallagher (sgallagh@redhat.com) wrote:
- 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.
Probably quite unrelated to the actual topic of this thread, but I just wanted to mention that we intend to move /etc/os-release to /usr/lib/os-release (and make /etc/os-release a symlink). We are working on making factory reset/stateless stuff work on Fedora, and this actually turned out to be one of the surprisingly few incomptibilities (the two other being dbus and PAM) we ran into. Placing this in /usr/lib is certainly the most appropriate place for it, after all it describes what /usr actually contains, not what /etc contains...
Anyway, just wanted to mention this. We will soon upload a new systemd release to Rawhide, that prepares everything for moving the file, will then file a bug against fedora-release asking for the file to be moved.
Lennart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/30/2014 03:39 PM, Lennart Poettering wrote:
On Mon, 30.06.14 14:59, Stephen Gallagher (sgallagh@redhat.com) wrote:
- 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.
Probably quite unrelated to the actual topic of this thread, but I just wanted to mention that we intend to move /etc/os-release to /usr/lib/os-release (and make /etc/os-release a symlink). We are working on making factory reset/stateless stuff work on Fedora, and this actually turned out to be one of the surprisingly few incomptibilities (the two other being dbus and PAM) we ran into. Placing this in /usr/lib is certainly the most appropriate place for it, after all it describes what /usr actually contains, not what /etc contains...
Anyway, just wanted to mention this. We will soon upload a new systemd release to Rawhide, that prepares everything for moving the file, will then file a bug against fedora-release asking for the file to be moved.
Sure, the real-world location of this file is pretty much immaterial, as long as we get it created properly.
Any chance that systemd wants to build a hostnamectl-like interface for setting the os-release values? That would make life a lot easier on us, as we could reconfigure that file if-and-when a fedora-release-$PRODUCT package was installed in a %post snippet.
On Mon, Jun 30, 2014 at 03:44:26PM -0400, Stephen Gallagher wrote:
Any chance that systemd wants to build a hostnamectl-like interface for setting the os-release values? That would make life a lot easier on us, as we could reconfigure that file if-and-when a fedora-release-$PRODUCT package was installed in a %post snippet.
What would be the advantage over including /usr/lib/os-release in the package directly? What kinds of fields could be modified in this way?
Zbyszek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/30/2014 04:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 30, 2014 at 03:44:26PM -0400, Stephen Gallagher wrote:
Any chance that systemd wants to build a hostnamectl-like interface for setting the os-release values? That would make life a lot easier on us, as we could reconfigure that file if-and-when a fedora-release-$PRODUCT package was installed in a %post snippet.
What would be the advantage over including /usr/lib/os-release in the package directly? What kinds of fields could be modified in this way?
Well, ideally we'd like the majority of the file to be owned by fedora-release and then just add the one or two additional fields specific to the products programmatically.
I suppose though that we could just carry complete duplicates in each fedora-release-* package. Particularly if we end up adding a fedora-release-nonproduct (or however we name it) package to solve the depsolving issues as suggested by James Antill.
On Mon, 30.06.14 16:16, Stephen Gallagher (sgallagh@redhat.com) wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/30/2014 04:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 30, 2014 at 03:44:26PM -0400, Stephen Gallagher wrote:
Any chance that systemd wants to build a hostnamectl-like interface for setting the os-release values? That would make life a lot easier on us, as we could reconfigure that file if-and-when a fedora-release-$PRODUCT package was installed in a %post snippet.
What would be the advantage over including /usr/lib/os-release in the package directly? What kinds of fields could be modified in this way?
Well, ideally we'd like the majority of the file to be owned by fedora-release and then just add the one or two additional fields specific to the products programmatically.
I suppose though that we could just carry complete duplicates in each fedora-release-* package. Particularly if we end up adding a fedora-release-nonproduct (or however we name it) package to solve the depsolving issues as suggested by James Antill.
I really don't understand why /usr/lib/os-release should have an API to modify. It describes the vendor operating system image, really, and his hence strictly not dynamic. We should never invent mechanisms that make files in /usr subject to runtime configuration. That would be completely backwards.
Lennart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/30/2014 04:22 PM, Lennart Poettering wrote:
On Mon, 30.06.14 16:16, Stephen Gallagher (sgallagh@redhat.com) wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/30/2014 04:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 30, 2014 at 03:44:26PM -0400, Stephen Gallagher wrote:
Any chance that systemd wants to build a hostnamectl-like interface for setting the os-release values? That would make life a lot easier on us, as we could reconfigure that file if-and-when a fedora-release-$PRODUCT package was installed in a %post snippet.
What would be the advantage over including /usr/lib/os-release in the package directly? What kinds of fields could be modified in this way?
Well, ideally we'd like the majority of the file to be owned by fedora-release and then just add the one or two additional fields specific to the products programmatically.
I suppose though that we could just carry complete duplicates in each fedora-release-* package. Particularly if we end up adding a fedora-release-nonproduct (or however we name it) package to solve the depsolving issues as suggested by James Antill.
I really don't understand why /usr/lib/os-release should have an API to modify. It describes the vendor operating system image, really, and his hence strictly not dynamic. We should never invent mechanisms that make files in /usr subject to runtime configuration. That would be completely backwards.
Well, it's semi-dynamic. I suppose I'm treating it more like an additive drop directory.
In a sense, there's a certain amount of this definition that every Fedora install will have. The Products then add to this definition. A basic piece of it is mandatory, but the outer edges are add-ons.
Since we can't change the standard that requires os-release to allow drop directory extension, that leaves either replacing the file completely (which is how we're likely to actually do it) or adding an API to allow extending it for limited cases such as evolving into one of the Products from a non-product starting point.
On Mon, 30.06.14 16:43, Stephen Gallagher (sgallagh@redhat.com) wrote:
Well, ideally we'd like the majority of the file to be owned by fedora-release and then just add the one or two additional fields specific to the products programmatically.
I suppose though that we could just carry complete duplicates in each fedora-release-* package. Particularly if we end up adding a fedora-release-nonproduct (or however we name it) package to solve the depsolving issues as suggested by James Antill.
I really don't understand why /usr/lib/os-release should have an API to modify. It describes the vendor operating system image, really, and his hence strictly not dynamic. We should never invent mechanisms that make files in /usr subject to runtime configuration. That would be completely backwards.
Well, it's semi-dynamic. I suppose I'm treating it more like an additive drop directory.
In a sense, there's a certain amount of this definition that every Fedora install will have. The Products then add to this definition. A basic piece of it is mandatory, but the outer edges are add-ons.
I am not sure this is really what /etc/os-release is for. It's for declaring operating system names and versions, not really for containing a list of packages you have installed.
Lennart
On Jun 30, 2014, at 5:15 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Mon, 30.06.14 16:43, Stephen Gallagher (sgallagh@redhat.com) wrote:
Well, ideally we'd like the majority of the file to be owned by fedora-release and then just add the one or two additional fields specific to the products programmatically.
I suppose though that we could just carry complete duplicates in each fedora-release-* package. Particularly if we end up adding a fedora-release-nonproduct (or however we name it) package to solve the depsolving issues as suggested by James Antill.
I really don't understand why /usr/lib/os-release should have an API to modify. It describes the vendor operating system image, really, and his hence strictly not dynamic. We should never invent mechanisms that make files in /usr subject to runtime configuration. That would be completely backwards.
Well, it's semi-dynamic. I suppose I'm treating it more like an additive drop directory.
In a sense, there's a certain amount of this definition that every Fedora install will have. The Products then add to this definition. A basic piece of it is mandatory, but the outer edges are add-ons.
I am not sure this is really what /etc/os-release is for. It's for declaring operating system names and versions, not really for containing a list of packages you have installed.
That's exactly what I'm describing, though. I'm not sure where you're getting "a list of packages you have installed" from. We're trying to describe that this OS is both "Fedora" and (over and above that) also "Fedora Server".
Lennart
-- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Mon, 30.06.14 17:31, Stephen Gallagher (sgallagh@redhat.com) wrote:
On Jun 30, 2014, at 5:15 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Mon, 30.06.14 16:43, Stephen Gallagher (sgallagh@redhat.com) wrote:
Well, ideally we'd like the majority of the file to be owned by fedora-release and then just add the one or two additional fields specific to the products programmatically.
I suppose though that we could just carry complete duplicates in each fedora-release-* package. Particularly if we end up adding a fedora-release-nonproduct (or however we name it) package to solve the depsolving issues as suggested by James Antill.
I really don't understand why /usr/lib/os-release should have an API to modify. It describes the vendor operating system image, really, and his hence strictly not dynamic. We should never invent mechanisms that make files in /usr subject to runtime configuration. That would be completely backwards.
Well, it's semi-dynamic. I suppose I'm treating it more like an additive drop directory.
In a sense, there's a certain amount of this definition that every Fedora install will have. The Products then add to this definition. A basic piece of it is mandatory, but the outer edges are add-ons.
I am not sure this is really what /etc/os-release is for. It's for declaring operating system names and versions, not really for containing a list of packages you have installed.
That's exactly what I'm describing, though. I'm not sure where you're getting "a list of packages you have installed" from. We're trying to describe that this OS is both "Fedora" and (over and above that) also "Fedora Server".
Well, either the OS is Fedora or it isn't. If it is Fedora, then "ID=fedora" should be set. If it isn't, then instead you should set "ID=fedora-foobar", but to express the compatibility you should also set "ID_LIKE=fedora". See os-release(5) for details on ID= and ID_LIKE=.
Lennart
On Mon, Jun 30, 2014 at 11:14:52PM +0200, Lennart Poettering wrote:
In a sense, there's a certain amount of this definition that every Fedora install will have. The Products then add to this definition. A basic piece of it is mandatory, but the outer edges are add-ons.
I am not sure this is really what /etc/os-release is for. It's for declaring operating system names and versions, not really for containing a list of packages you have installed.
We're not (ultimately, at least), just talking about a list of packages. It is like a sub-version of the operating system. A "flavor", perhaps. Using a different ID and ID_LIKE=fedora seems a) far too heavy and b) expressive of a much larger difference.
I *do* like that you're planning to move this to /usr/lib. It never made sense to me as _configuration_.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/03/2014 05:47 PM, Matthew Miller wrote:
On Mon, Jun 30, 2014 at 11:14:52PM +0200, Lennart Poettering wrote:
In a sense, there's a certain amount of this definition that every Fedora install will have. The Products then add to this definition. A basic piece of it is mandatory, but the outer edges are add-ons.
I am not sure this is really what /etc/os-release is for. It's for declaring operating system names and versions, not really for containing a list of packages you have installed.
We're not (ultimately, at least), just talking about a list of packages. It is like a sub-version of the operating system. A "flavor", perhaps. Using a different ID and ID_LIKE=fedora seems a) far too heavy and b) expressive of a much larger difference.
Well, given that the standard doesn't *really* have this level of nuance, I'm inclined to agree with this approach.
So we'd have ID=fedora-cloud ID_LIKE=fedora
and so on. It doesn't really seem likely to cause too much confusion, IMHO.
I *do* like that you're planning to move this to /usr/lib. It never made sense to me as _configuration_.
Agreed
On Mon, Jun 30, 2014 at 03:44:26PM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/30/2014 03:39 PM, Lennart Poettering wrote:
On Mon, 30.06.14 14:59, Stephen Gallagher (sgallagh@redhat.com) wrote:
- 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.
Probably quite unrelated to the actual topic of this thread, but I just wanted to mention that we intend to move /etc/os-release to /usr/lib/os-release (and make /etc/os-release a symlink). We are working on making factory reset/stateless stuff work on Fedora, and this actually turned out to be one of the surprisingly few incomptibilities (the two other being dbus and PAM) we ran into. Placing this in /usr/lib is certainly the most appropriate place for it, after all it describes what /usr actually contains, not what /etc contains...
Anyway, just wanted to mention this. We will soon upload a new systemd release to Rawhide, that prepares everything for moving the file, will then file a bug against fedora-release asking for the file to be moved.
Sure, the real-world location of this file is pretty much immaterial, as long as we get it created properly.
Provided the symlink remains in place for a very long time ...
Any chance that systemd wants to build a hostnamectl-like interface for setting the os-release values? That would make life a lot easier on us, as we could reconfigure that file if-and-when a fedora-release-$PRODUCT package was installed in a %post snippet.
As long as you don't require running special programs in order to make changes to what are basically configuration files.
Rich.
On Mon, 2014-06-30 at 14:59 -0400, Stephen Gallagher wrote:
Additionally, I am working on a proposal[1] for per-product configs in
I think you can go with something very close to this design _if_ you always have a product. This would mean that even a minimal Fedora install would need a system-release-minimal, or whatever. Then all the product subpackages can use the "least requires wins" method of compare providers to make it work (the above is said without any testing). You can keep all the conflicts, but they are more like asserts than something used to help pick the correct subpackage, currently.
the Fedora 21 timeframe which is dependent on the above. It should be noted that this is an interim solution only; in Fedora 22 we will be able to vastly simplify this situation with the weak dependency support in RPM 4.12. (I was looking for a link detailing all of these weak deps, but I cannot find one. If you know of such a document, please reply and add it).
I don't see how weak deps. will solve any of your problems. If dnf +rpmbuild+createrepo/etc also has support for the planned _rich_ deps. then you should be able to do something like:
Require: config-server if system-release-server (is installed) Require: config-workstation if system-release-workstation (is installed)
...which is what you are trying to express. Also DNF should be better able to handle the conflicts with backtracking too, so there's that.
[1] https://fedoraproject.org/wiki/Per-Product_Configuration_Packaging_Draft
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/30/2014 03:54 PM, James Antill wrote:
On Mon, 2014-06-30 at 14:59 -0400, Stephen Gallagher wrote:
Additionally, I am working on a proposal[1] for per-product configs in
I think you can go with something very close to this design _if_ you always have a product. This would mean that even a minimal Fedora install would need a system-release-minimal, or whatever. Then all the product subpackages can use the "least requires wins" method of compare providers to make it work (the above is said without any testing). You can keep all the conflicts, but they are more like asserts than something used to help pick the correct subpackage, currently.
So for F21 at least, we may have to go with "what you start with is what you're stuck with" as an approach and solve it better in the future.
the Fedora 21 timeframe which is dependent on the above. It should be noted that this is an interim solution only; in Fedora 22 we will be able to vastly simplify this situation with the weak dependency support in RPM 4.12. (I was looking for a link detailing all of these weak deps, but I cannot find one. If you know of such a document, please reply and add it).
I don't see how weak deps. will solve any of your problems. If dnf +rpmbuild+createrepo/etc also has support for the planned _rich_ deps. then you should be able to do something like:
Require: config-server if system-release-server (is installed) Require: config-workstation if system-release-workstation (is installed)
...which is what you are trying to express. Also DNF should be better able to handle the conflicts with backtracking too, so there's that.
Right, I said "weak" when I mean "rich", which is extremely embarassing :)
But yeah, that's pretty much what we want there and if we can push hard for that in Fedora 22, I think that's a major win.
[1] https://fedoraproject.org/wiki/Per-Product_Configuration_Packaging_Draft
Dne 30.6.2014 20:59, Stephen Gallagher napsal(a):
- 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.
Could you please clarify, if you are going to preserve /etc/fedora-release on not? It is unclear to me from your wording ...
Vít
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/01/2014 04:26 AM, Vít Ondruch wrote:
Dne 30.6.2014 20:59, Stephen Gallagher napsal(a):
- 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.
Could you please clarify, if you are going to preserve /etc/fedora-release on not? It is unclear to me from your wording ...
Yes, sorry. We will preserve /etc/fedora-release, these files will be supplementary, not a replacement.
Dne 1.7.2014 14:37, Stephen Gallagher napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/01/2014 04:26 AM, Vít Ondruch wrote:
Dne 30.6.2014 20:59, Stephen Gallagher napsal(a):
- 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.
Could you please clarify, if you are going to preserve /etc/fedora-release on not? It is unclear to me from your wording ...
Yes, sorry. We will preserve /etc/fedora-release, these files will be supplementary, not a replacement.
Great, thanks for clarification.
Vít
On Mon, Jun 30, 2014 at 02:59:20PM -0400, Stephen Gallagher wrote:
- 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.
Note that agetty(8) allows to keep /etc/issue distribution independent and it reads all necessary information from /etc/os-release to generate the final pre-login message. All you need is to create /etc/issue with \S sequences, for example:
\S{PRETTY_NAME} \S{HOME_URL}
Kernel \r on an \m (\l)
.. so /etc/issue does not have to be maintained within packages like fedora-release-$PRODUCT or so.
It would be really really nice have only *one* file (/etc/os-release) that contains operating system identification data. The mess like /etc/fedora-release and /etc/redhat-release should be deprecated.
Karel
On Wed, Jul 02, 2014 at 10:38:15AM +0200, Karel Zak wrote:
Note that agetty(8) allows to keep /etc/issue distribution independent and it reads all necessary information from /etc/os-release to generate the final pre-login message. All you need is to create /etc/issue with \S sequences, for example: \S{PRETTY_NAME} \S{HOME_URL} Kernel \r on an \m (\l) .. so /etc/issue does not have to be maintained within packages like fedora-release-$PRODUCT or so.
Oh, that's nice. I just learned yesterday that it has all of those fancy new escapes.
It would be really really nice have only *one* file (/etc/os-release) that contains operating system identification data. The mess like /etc/fedora-release and /etc/redhat-release should be deprecated.
Yeah. The tricky thing is providing "sub-release" information when there's just one file. Maybe something like "/etc/os-release.d/" could solve the problem....
----- Original Message -----
On Wed, Jul 02, 2014 at 10:38:15AM +0200, Karel Zak wrote:
It would be really really nice have only *one* file (/etc/os-release) that contains operating system identification data. The mess like /etc/fedora-release and /etc/redhat-release should be deprecated.
Yeah. The tricky thing is providing "sub-release" information when there's just one file. Maybe something like "/etc/os-release.d/" could solve the problem....
It really seems to me that it’s way too early to generalize this into a general mechanism we don’t really need, but would have to keep supporting for years. AFAICT a (probably Fedora-specific) patch to login(1) that specifically hard-coded detection of a Fedora product, and added an appropriate message in to contents of /etc/issue, would be a smaller maintenance burden than any of the generic proposals, would work just as well, and would give us a full freedom to change our mind about the implementation later. Mirek
On Wed, Jul 02, 2014 at 09:47:26AM -0400, Miloslav Trmač wrote:
----- Original Message -----
On Wed, Jul 02, 2014 at 10:38:15AM +0200, Karel Zak wrote:
It would be really really nice have only *one* file (/etc/os-release) that contains operating system identification data. The mess like /etc/fedora-release and /etc/redhat-release should be deprecated.
Yeah. The tricky thing is providing "sub-release" information when there's just one file. Maybe something like "/etc/os-release.d/" could solve the problem....
It really seems to me that it’s way too early to generalize this into a general mechanism we don’t really need, but would have to keep supporting for years. AFAICT a (probably Fedora-specific) patch to login(1) that specifically hard-coded detection of a Fedora product, and added an appropriate message in to contents of /etc/issue, would be a smaller maintenance burden than any of the generic proposals, would work just as well, and would give us a full freedom to change our mind about the implementation later.
That's an unnecessary overcomplication too. Just put:
------------- /etc/issue -------------- -- \S{PRETTY_NAME} -- Kernel \r on an \m (\l)
---------------------------------------
and
------------- /etc/os-release --------- ... PRETTY_NAME="Fedora 21 server (Rawhide)" ... ---------------------------------------
Works as expected.
Zbyszek
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).
How will this work with fedup from 20 to 21? Will there be multiple upgrade targets?
On 07/02/2014 06:55 PM, William wrote:
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).
How will this work with fedup from 20 to 21? Will there be multiple upgrade targets?
Why would that be necessary? All packages are in one repository, so fedora-release-$PRODUCT will be upgraded to the next version and everything will be fine.
On Wed, 2014-07-02 at 20:40 -0700, Samuel Sieb wrote:
On 07/02/2014 06:55 PM, William wrote:
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).
How will this work with fedup from 20 to 21? Will there be multiple upgrade targets?
Why would that be necessary? All packages are in one repository, so fedora-release-$PRODUCT will be upgraded to the next version and everything will be fine.
My machine doesn't currently have a fedora-release-$PRODUCT package installed. So how will fedup work out what one to put on my system? Will these packages be added to 20, and the user need to preinstall before fedup?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/03/2014 01:42 AM, William wrote:
On Wed, 2014-07-02 at 20:40 -0700, Samuel Sieb wrote:
On 07/02/2014 06:55 PM, William wrote:
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).
How will this work with fedup from 20 to 21? Will there be multiple upgrade targets?
Why would that be necessary? All packages are in one repository, so fedora-release-$PRODUCT will be upgraded to the next version and everything will be fine.
My machine doesn't currently have a fedora-release-$PRODUCT package installed. So how will fedup work out what one to put on my system? Will these packages be added to 20, and the user need to preinstall before fedup?
It won't put one on your system. Upgrades from a non-Productized Fedora will remain non-Productized. It's not *less* Fedora than before.
The Products are basically a statement that "this minimal set of packages and services are available on the system". A non-productized Fedora install is essentially just a continuation of the classic do-it-yourself approach that Fedora has been up to this point.
I hope that clarifies things for you.
On Thu, Jul 3, 2014 at 9:57 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/03/2014 01:42 AM, William wrote:
On Wed, 2014-07-02 at 20:40 -0700, Samuel Sieb wrote:
On 07/02/2014 06:55 PM, William wrote:
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).
How will this work with fedup from 20 to 21? Will there be multiple upgrade targets?
Why would that be necessary? All packages are in one repository, so fedora-release-$PRODUCT will be upgraded to the next version and everything will be fine.
My machine doesn't currently have a fedora-release-$PRODUCT package installed. So how will fedup work out what one to put on my system? Will these packages be added to 20, and the user need to preinstall before fedup?
It won't put one on your system. Upgrades from a non-Productized Fedora will remain non-Productized. It's not *less* Fedora than before.
The Products are basically a statement that "this minimal set of packages and services are available on the system". A non-productized Fedora install is essentially just a continuation of the classic do-it-yourself approach that Fedora has been up to this point.
That's misleading. Fedora hasn't been releasing "do-it-yourself" releases. Our previous install images were composed and tested by QA, including testing fedup upgrades from the previous release. With Fedora.next, we don't have an install image that is an equivalent of <= F20.
Perhaps I have missed them, but I've seen no discussion or plans around testing upgrades to F21 from F20. Unless the Products intend to test upgrading from F20, and/or QA intends to somehow test fedup from F20 to F21 in a non-product manner, we're essentially changing the semantics of upgrades. I agree it should still work, but saying it's a continuation of existing practice when it isn't is wrong.
josh
On Thu, 2014-07-03 at 10:05 -0400, Josh Boyer wrote:
On Thu, Jul 3, 2014 at 9:57 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/03/2014 01:42 AM, William wrote:
On Wed, 2014-07-02 at 20:40 -0700, Samuel Sieb wrote:
On 07/02/2014 06:55 PM, William wrote:
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).
How will this work with fedup from 20 to 21? Will there be multiple upgrade targets?
Why would that be necessary? All packages are in one repository, so fedora-release-$PRODUCT will be upgraded to the next version and everything will be fine.
My machine doesn't currently have a fedora-release-$PRODUCT package installed. So how will fedup work out what one to put on my system? Will these packages be added to 20, and the user need to preinstall before fedup?
It won't put one on your system. Upgrades from a non-Productized Fedora will remain non-Productized. It's not *less* Fedora than before.
The Products are basically a statement that "this minimal set of packages and services are available on the system". A non-productized Fedora install is essentially just a continuation of the classic do-it-yourself approach that Fedora has been up to this point.
That's misleading. Fedora hasn't been releasing "do-it-yourself" releases. Our previous install images were composed and tested by QA, including testing fedup upgrades from the previous release. With Fedora.next, we don't have an install image that is an equivalent of <= F20.
Perhaps I have missed them, but I've seen no discussion or plans around testing upgrades to F21 from F20. Unless the Products intend to test upgrading from F20, and/or QA intends to somehow test fedup from F20 to F21 in a non-product manner, we're essentially changing the semantics of upgrades. I agree it should still work, but saying it's a continuation of existing practice when it isn't is wrong.
josh
It's also misleading given how much focus has been given to the three new products that will be released: So why now is there a "non-productised" version? That's not been advertised much.
I think that some attention needs to be paid to the F20 -> F21 upgrade path, and it shouldn't be left to the last minute. Do you need to choose a product via fedup at upgrade time? Do you support a non-productised version?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/06/2014 03:43 AM, William wrote:
On Thu, 2014-07-03 at 10:05 -0400, Josh Boyer wrote:
On Thu, Jul 3, 2014 at 9:57 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/03/2014 01:42 AM, William wrote:
On Wed, 2014-07-02 at 20:40 -0700, Samuel Sieb wrote:
On 07/02/2014 06:55 PM, William wrote:
> 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).
How will this work with fedup from 20 to 21? Will there be multiple upgrade targets?
Why would that be necessary? All packages are in one repository, so fedora-release-$PRODUCT will be upgraded to the next version and everything will be fine.
My machine doesn't currently have a fedora-release-$PRODUCT package installed. So how will fedup work out what one to put on my system? Will these packages be added to 20, and the user need to preinstall before fedup?
It won't put one on your system. Upgrades from a non-Productized Fedora will remain non-Productized. It's not *less* Fedora than before.
The Products are basically a statement that "this minimal set of packages and services are available on the system". A non-productized Fedora install is essentially just a continuation of the classic do-it-yourself approach that Fedora has been up to this point.
That's misleading. Fedora hasn't been releasing "do-it-yourself" releases. Our previous install images were composed and tested by QA, including testing fedup upgrades from the previous release. With Fedora.next, we don't have an install image that is an equivalent of <= F20.
Perhaps I have missed them, but I've seen no discussion or plans around testing upgrades to F21 from F20. Unless the Products intend to test upgrading from F20, and/or QA intends to somehow test fedup from F20 to F21 in a non-product manner, we're essentially changing the semantics of upgrades. I agree it should still work, but saying it's a continuation of existing practice when it isn't is wrong.
josh
It's also misleading given how much focus has been given to the three new products that will be released: So why now is there a "non-productised" version? That's not been advertised much.
I honestly don't know how much more we could have advertised that. We've been talking about it since the beginning. Particularly about how the Fedora Products are additive to the classic Fedora and that spins aren't going away (they're non-productized versions too).
I've talked about this until I was blue in the face at every opportunity. Please do not confuse "I missed this" with "It wasn't advertised".
I think that some attention needs to be paid to the F20 -> F21 upgrade path, and it shouldn't be left to the last minute. Do you need to choose a product via fedup at upgrade time? Do you support a non-productised version?
Of course attention is going to be paid here. But it really should be no different than existing upgrades. If you want to pick a product after upgrade, you just 'yum install fedora-release-$PRODUCT' and you'll get the new release file that includes the hard requirements to be that Product. If you don't install that release package, you'll essentially just remain a DIY environment.
At least, this is the way I've been envisioning it and describing for a long time now. If we're going to change this plan, I feel like the week of Alpha Freeze is probably kind of late...
On Mon, Jul 7, 2014 at 9:02 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/06/2014 03:43 AM, William wrote:
On Thu, 2014-07-03 at 10:05 -0400, Josh Boyer wrote:
On Thu, Jul 3, 2014 at 9:57 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/03/2014 01:42 AM, William wrote:
On Wed, 2014-07-02 at 20:40 -0700, Samuel Sieb wrote:
On 07/02/2014 06:55 PM, William wrote: > >> 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). > > How will this work with fedup from 20 to 21? Will there > be multiple upgrade targets? > Why would that be necessary? All packages are in one repository, so fedora-release-$PRODUCT will be upgraded to the next version and everything will be fine.
My machine doesn't currently have a fedora-release-$PRODUCT package installed. So how will fedup work out what one to put on my system? Will these packages be added to 20, and the user need to preinstall before fedup?
It won't put one on your system. Upgrades from a non-Productized Fedora will remain non-Productized. It's not *less* Fedora than before.
The Products are basically a statement that "this minimal set of packages and services are available on the system". A non-productized Fedora install is essentially just a continuation of the classic do-it-yourself approach that Fedora has been up to this point.
That's misleading. Fedora hasn't been releasing "do-it-yourself" releases. Our previous install images were composed and tested by QA, including testing fedup upgrades from the previous release. With Fedora.next, we don't have an install image that is an equivalent of <= F20.
Perhaps I have missed them, but I've seen no discussion or plans around testing upgrades to F21 from F20. Unless the Products intend to test upgrading from F20, and/or QA intends to somehow test fedup from F20 to F21 in a non-product manner, we're essentially changing the semantics of upgrades. I agree it should still work, but saying it's a continuation of existing practice when it isn't is wrong.
josh
It's also misleading given how much focus has been given to the three new products that will be released: So why now is there a "non-productised" version? That's not been advertised much.
I honestly don't know how much more we could have advertised that. We've been talking about it since the beginning. Particularly about how the Fedora Products are additive to the classic Fedora and that spins aren't going away (they're non-productized versions too).
You're talking about additive in the "they all use the same repos" sense, but there is no planned install media that will be produced similar to the F20 release. There are the 3 products, and there are the spins. The product closest to the existing Fedora default is Workstation, and we're targeting a live media as the primary deliverable. There have been 0 plans or discussions around fedup/upgrades from F20 so far.
I've talked about this until I was blue in the face at every opportunity. Please do not confuse "I missed this" with "It wasn't advertised".
At some point, less talking and more actual planning/doing is needed. I've seen no work put towards upgrade paths at all.
I think that some attention needs to be paid to the F20 -> F21 upgrade path, and it shouldn't be left to the last minute. Do you need to choose a product via fedup at upgrade time? Do you support a non-productised version?
Of course attention is going to be paid here. But it really should be
"going to be" is the main problem.
no different than existing upgrades. If you want to pick a product after upgrade, you just 'yum install fedora-release-$PRODUCT' and you'll get the new release file that includes the hard requirements to be that Product. If you don't install that release package, you'll essentially just remain a DIY environment.
At least, this is the way I've been envisioning it and describing for a long time now. If we're going to change this plan, I feel like the week of Alpha Freeze is probably kind of late...
That isn't a plan. It's a fuzzy idea of how it should work. If that's what we think we should do, we need to actually get people on board with it, start working out the details, and start testing things.
josh
On 7 Jul 2014, at 11:17, Josh Boyer wrote:
On Mon, Jul 7, 2014 at 9:02 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/06/2014 03:43 AM, William wrote:
On Thu, 2014-07-03 at 10:05 -0400, Josh Boyer wrote:
That's misleading. Fedora hasn't been releasing "do-it-yourself" releases. Our previous install images were composed and tested by QA, including testing fedup upgrades from the previous release. With Fedora.next, we don't have an install image that is an equivalent of <= F20.
Perhaps I have missed them, but I've seen no discussion or plans around testing upgrades to F21 from F20. Unless the Products intend to test upgrading from F20, and/or QA intends to somehow test fedup from F20 to F21 in a non-product manner, we're essentially changing the semantics of upgrades. I agree it should still work, but saying it's a continuation of existing practice when it isn't is wrong.
josh
It's also misleading given how much focus has been given to the three new products that will be released: So why now is there a "non-productised" version? That's not been advertised much.
I honestly don't know how much more we could have advertised that. We've been talking about it since the beginning. Particularly about how the Fedora Products are additive to the classic Fedora and that spins aren't going away (they're non-productized versions too).
You're talking about additive in the "they all use the same repos" sense, but there is no planned install media that will be produced similar to the F20 release. There are the 3 products, and there are the spins. The product closest to the existing Fedora default is Workstation, and we're targeting a live media as the primary deliverable. There have been 0 plans or discussions around fedup/upgrades from F20 so far.
While I appreciate that the Fedora project has goals that it wants to achieve with the three new "products", I had assumed based on the explanations that I have read that:
1. There will not be any change in the repo structure -- no separate repos for separate "products".
2. For those of us who are not interested in the new "products" or do not find their minimum package assurances to be important in our use cases, there will still be a traditional "non-productized" Fedora.
3. There will still be plain "non-productized" versions of /etc/os- release (or wherever the systemd guys are relocating it) and /etc/ fedora-release.
4. There would be, at least, a net install CD to install a traditional "non-productized" Fedora system.
5. A fedup upgrade will be possible from a traditional "non- productized" Fedora 20 system to a traditional "non-productized" Fedora 21 system and, in due time, from traditional "non-productized" Fedora 21 to 22, etc.
Am I mistaken on any or all of this?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/09/2014 03:07 PM, Mike Pinkerton wrote:
On 7 Jul 2014, at 11:17, Josh Boyer wrote:
On Mon, Jul 7, 2014 at 9:02 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/06/2014 03:43 AM, William wrote:
On Thu, 2014-07-03 at 10:05 -0400, Josh Boyer wrote:
That's misleading. Fedora hasn't been releasing "do-it-yourself" releases. Our previous install images were composed and tested by QA, including testing fedup upgrades from the previous release. With Fedora.next, we don't have an install image that is an equivalent of <= F20.
Perhaps I have missed them, but I've seen no discussion or plans around testing upgrades to F21 from F20. Unless the Products intend to test upgrading from F20, and/or QA intends to somehow test fedup from F20 to F21 in a non-product manner, we're essentially changing the semantics of upgrades. I agree it should still work, but saying it's a continuation of existing practice when it isn't is wrong.
josh
It's also misleading given how much focus has been given to the three new products that will be released: So why now is there a "non-productised" version? That's not been advertised much.
I honestly don't know how much more we could have advertised that. We've been talking about it since the beginning. Particularly about how the Fedora Products are additive to the classic Fedora and that spins aren't going away (they're non-productized versions too).
You're talking about additive in the "they all use the same repos" sense, but there is no planned install media that will be produced similar to the F20 release. There are the 3 products, and there are the spins. The product closest to the existing Fedora default is Workstation, and we're targeting a live media as the primary deliverable. There have been 0 plans or discussions around fedup/upgrades from F20 so far.
While I appreciate that the Fedora project has goals that it wants to achieve with the three new "products", I had assumed based on the explanations that I have read that:
- There will not be any change in the repo structure -- no
separate repos for separate "products".
This is true.
- For those of us who are not interested in the new "products" or
do not find their minimum package assurances to be important in our use cases, there will still be a traditional "non-productized" Fedora.
This is nuanced. Fedora as a non-Productized repository will exist. See below.
- There will still be plain "non-productized" versions of
/etc/os-release (or wherever the systemd guys are relocating it) and /etc/fedora-release.
This is true.
- There would be, at least, a net install CD to install a
traditional "non-productized" Fedora system.
This is not strictly true. The *official* install media will be for one of the Products. There will also be install media and/or live images for the Spins. These Spins will essentially be installing specific package sets from non-productized Fedora.
I do not know which or if any Spins will be providing the specific net install CD you're asking about. This will not be an *official* (read: tested by QA) method of installing Fedora. However, I see no reason why it wouldn't work.
- A fedup upgrade will be possible from a traditional
"non-productized" Fedora 20 system to a traditional "non-productized" Fedora 21 system and, in due time, from traditional "non-productized" Fedora 21 to 22, etc.
This statement is true for F20->F21. For F21->F22, I want it to be possible to go from "non-productized" to "productized" *if the user wishes* (opt-in, not opt-out).
Am I mistaken on any or all of this?
On Wed, Jul 09, 2014 at 04:42:23PM -0400, Stephen Gallagher wrote:
I do not know which or if any Spins will be providing the specific net install CD you're asking about. This will not be an *official* (read: tested by QA) method of installing Fedora. However, I see no reason why it wouldn't work.
A few months ago* I remember the server WG talking about providing a minimal/netinstall image. Has this changed?
* dredges up meeting logs -- http://meetbot.fedoraproject.org/teams/server-wg/server-wg.2014-02-25-16.00....
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/09/2014 05:08 PM, Matthew Miller wrote:
On Wed, Jul 09, 2014 at 04:42:23PM -0400, Stephen Gallagher wrote:
I do not know which or if any Spins will be providing the specific net install CD you're asking about. This will not be an *official* (read: tested by QA) method of installing Fedora. However, I see no reason why it wouldn't work.
A few months ago* I remember the server WG talking about providing a minimal/netinstall image. Has this changed?
- dredges up meeting logs --
http://meetbot.fedoraproject.org/teams/server-wg/server-wg.2014-02-25-16.00....
That's why I said the *specific* netinstall he was asking for. The Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: "4. There would be, at least, a net install CD to install a traditional "non-productized" Fedora system."
On 10 Jul 2014, at 07:04, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/09/2014 05:08 PM, Matthew Miller wrote:
On Wed, Jul 09, 2014 at 04:42:23PM -0400, Stephen Gallagher wrote:
I do not know which or if any Spins will be providing the specific net install CD you're asking about. This will not be an *official* (read: tested by QA) method of installing Fedora. However, I see no reason why it wouldn't work.
A few months ago* I remember the server WG talking about providing a minimal/netinstall image. Has this changed?
- dredges up meeting logs --
http://meetbot.fedoraproject.org/teams/server-wg/server-wg. 2014-02-25-16.00.html
That's why I said the *specific* netinstall he was asking for. The Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: "4. There would be, at least, a net install CD to install a traditional "non-productized" Fedora system."
A minimal netinstall would be ok if there is a simple way to replace the "productized" fedora-release package with a plain, non- productized fedora-release package.
In saying that, I am making an assumption that, once the fedora- release package is switched out, then any "product" requirements or constraints would disappear and the system would be a traditional, non-productized Fedora system that could then be configured however the system administrator chose.
Is that assumption wrong?
Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/10/2014 09:53 AM, Mike Pinkerton wrote:
On 10 Jul 2014, at 07:04, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/09/2014 05:08 PM, Matthew Miller wrote:
On Wed, Jul 09, 2014 at 04:42:23PM -0400, Stephen Gallagher wrote:
I do not know which or if any Spins will be providing the specific net install CD you're asking about. This will not be an *official* (read: tested by QA) method of installing Fedora. However, I see no reason why it wouldn't work.
A few months ago* I remember the server WG talking about providing a minimal/netinstall image. Has this changed?
- dredges up meeting logs --
http://meetbot.fedoraproject.org/teams/server-wg/server-wg.2014-02-25-16.00....
That's why I said the *specific* netinstall he was asking for. The
Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: "4. There would be, at least, a net install CD to install a traditional "non-productized" Fedora system."
A minimal netinstall would be ok if there is a simple way to replace the "productized" fedora-release package with a plain, non-productized fedora-release package.
In saying that, I am making an assumption that, once the fedora-release package is switched out, then any "product" requirements or constraints would disappear and the system would be a traditional, non-productized Fedora system that could then be configured however the system administrator chose.
Is that assumption wrong?
Thanks.
That is the intent of the design, yes. We're dealing with some real-world issues with that (namely that the way dependency-processing works in yum and dnf has issues with this), so it may require us to code up a special tool to switch from productized to non-productized and vice-versa.
Stop reading now if you don't care about minutia:
Basically, in order to swap out the productized and non-productized release packages, it's not actually as simple as 'yum swap fedora-release-standard fedora-release-server'. The way the dependency processing works in yum and dnf will generally fall over and fail to properly detect the other packages that would need to be swapped (such as firewalld-config-standard -> firewalld-config-server). So what we will probably need to do is write a tool that will examine the RPM database for all product-specific packages and swap them in a single transaction. This is hard to do *generically*, but if everyone sticks with the convention mandated by my proposed Draft, it becomes a pattern-match instead of a deep dependency comparison (which is probably "good enough" for the first pass).
There's also a significant hope that future RPM enhancements (with complex and powerful deps like "if foo is installed, then install bar") will allow us to make this a much more simple process.
On 07/10/2014 04:34 PM, Stephen Gallagher wrote:
Basically, in order to swap out the productized and non-productized release packages, it's not actually as simple as 'yum swap fedora-release-standard fedora-release-server'. The way the dependency processing works in yum and dnf will generally fall over and fail to properly detect the other packages that would need to be swapped (such as firewalld-config-standard -> firewalld-config-server).
dnf seems able to figure out even the firewalld-config-* swap fine:
$ sudo dnf install fedora-release-workstation --allowerasing Dependencies resolved.
================================================================================ Package Arch Version Repository Size ================================================================================ Installing: fedora-release-workstation noarch 21-0.9 rawhide 17 k firewalld-config-workstation noarch 0.3.10-4.fc21 rawhide 40 k Removing: fedora-release-server noarch 21-0.9 @System 1.0 k firewalld-config-server noarch 0.3.10-4.fc21 @System 1.0 k
Transaction Summary ================================================================================ Install 2 Packages Remove 2 Packages
Total download size: 57 k Is this ok [y/N]: ...
Michal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/10/2014 12:45 PM, Michal Schmidt wrote:
On 07/10/2014 04:34 PM, Stephen Gallagher wrote:
Basically, in order to swap out the productized and non-productized release packages, it's not actually as simple as 'yum swap fedora-release-standard fedora-release-server'. The way the dependency processing works in yum and dnf will generally fall over and fail to properly detect the other packages that would need to be swapped (such as firewalld-config-standard -> firewalld-config-server).
dnf seems able to figure out even the firewalld-config-* swap fine:
$ sudo dnf install fedora-release-workstation --allowerasing Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
fedora-release-workstation noarch 21-0.9 rawhide 17 k firewalld-config-workstation noarch 0.3.10-4.fc21 rawhide 40 k Removing: fedora-release-server noarch 21-0.9 @System 1.0 k firewalld-config-server noarch 0.3.10-4.fc21 @System 1.0 k
Transaction Summary
Install 2 Packages
Remove 2 Packages
Total download size: 57 k Is this ok [y/N]: ...
Michal
Ok, that's really good to know. Yum however does not resolve this correctly, and yum is our default package manager.
I just tried:
[sgallagh@sgallagh540:~]$ sudo yum install fedora-release-server - --disablerepo=fedora --disablerepo=updates --enablerepo=rawhide - --disablerepo=updates-testingLoaded plugins: auto-update-debuginfo, langpacks bluejeans | 2.9 kB 00:00 google-chrome | 951 B 00:00 sgallagh-chrome-compat-libgcrypt | 3.0 kB 00:00 Resolving Dependencies - --> Running transaction check - ---> Package fedora-release-server.noarch 0:21-0.9 will be installed - --> Processing Conflict: fedora-release-workstation-21-0.9.noarch conflicts fedora-release-server - --> Processing Conflict: fedora-release-server-21-0.9.noarch conflicts fedora-release-workstation - --> Finished Dependency Resolution Error: fedora-release-workstation conflicts with fedora-release-server-21-0.9.noarch Error: fedora-release-server conflicts with fedora-release-workstation-21-0.9.noarch You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
And also:
[sgallagh@sgallagh540:~]$ sudo yum swap fedora-release-workstation fedora-release-server --disablerepo=fedora --disablerepo=updates - --enablerepo=rawhide --disablerepo=updates-testing Loaded plugins: auto-update-debuginfo, langpacks (1/2): rawhide/x86_64/primary_db | 17 MB 00:02 (2/2): rawhide-debuginfo/x86_64/primary_db | 1.7 MB 00:06 Resolving Dependencies - --> Running transaction check - ---> Package fedora-release-server.noarch 0:21-0.9 will be installed - ---> Package fedora-release-workstation.noarch 0:21-0.9 will be erased - --> Processing Dependency: system-release-workstation for package: firewalld-config-workstation-0.3.10-4.fc21.noarch - --> Running transaction check - ---> Package firewalld-config-workstation.noarch 0:0.3.10-4.fc21 will be erased - --> Processing Dependency: firewalld-config for package: firewalld-0.3.10-4.fc21.noarch - --> Running transaction check - ---> Package firewalld.noarch 0:0.3.10-4.fc21 will be erased - --> Processing Dependency: firewalld = 0.3.10-4.fc21 for package: firewall-config-0.3.10-4.fc21.noarch - --> Running transaction check - ---> Package firewall-config.noarch 0:0.3.10-4.fc21 will be erased - --> Finished Dependency Resolution
Dependencies Resolved
================================================================================ Package Arch Version Repository Size ================================================================================ Installing: fedora-release-server noarch 21-0.9 rawhide 17 k Removing: fedora-release-workstation noarch 21-0.9 installed 1.0 k Removing for dependencies: firewall-config noarch 0.3.10-4.fc21 installed 778 k firewalld noarch 0.3.10-4.fc21 installed 2.1 M firewalld-config-workstation noarch 0.3.10-4.fc21 installed 1.0 k
Transaction Summary ================================================================================ Install 1 Package Remove 1 Package (+3 Dependent packages)
Total download size: 17 k Is this ok [y/d/N]: n Exiting on user command Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx.2014-07-10.12-49.uQjUpN.yumtx
Neither of these approaches with yum worked correctly. It's good to know that about dnf though..
On Thu, Jul 10, 2014 at 07:04:21AM -0400, Stephen Gallagher wrote:
http://meetbot.fedoraproject.org/teams/server-wg/server-wg.2014-02-25-16.00....
That's why I said the *specific* netinstall he was asking for. The Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: "4. There would be, at least, a net install CD to install a traditional "non-productized" Fedora system."
Which totally makes sense from the Server WG pov, of course. Digging further into the logs, I find
16:42:53 <nirik> mitr: I guess I'd be ok with that... then leave netinstall for base
Since I know Base has decided to include anaconda in their circle, I'm going to ask if that group is interested in producing a non-productized minimal netinstall -- possibly as a spin. If they're not, this is probably a "help wanted" for someone else interested in this existing.
On 07/10/2014 05:22 PM, Matthew Miller wrote:
On Thu, Jul 10, 2014 at 07:04:21AM -0400, Stephen Gallagher wrote:
http://meetbot.fedoraproject.org/teams/server-wg/server-wg.2014-02-25-16.00....
That's why I said the *specific* netinstall he was asking for. The Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: "4. There would be, at least, a net install CD to install a traditional "non-productized" Fedora system."
Which totally makes sense from the Server WG pov, of course. Digging further into the logs, I find
16:42:53 <nirik> mitr: I guess I'd be ok with that... then leave netinstall for base
Since I know Base has decided to include anaconda in their circle, I'm going to ask if that group is interested in producing a non-productized minimal netinstall -- possibly as a spin. If they're not, this is probably a "help wanted" for someone else interested in this existing.
With my Workstation WG member hat on: if Base is willing to pick up netinstall (both the boot.iso and PXE), we would love that.
We originally wanted to ship only the live media for F21 Workstation, but releng convinced us (or forced might be a better word :-) to ship netinstall as well. Releng's reasoning was that we can't leave it out of Workstation because otherwise Fedora would have no working netinstall. Which makes a lot of sense on one hand, but on the other hand a netinstall that can only install Workstation might not be what users expect.
If there's an option of producing a generic, non-productized netinstall, that would be best and we would be able to drop this from Workstation.