Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO+czUACgkQeiVVYja6o6MglgCgqA5z48SkYRN3Nx8QaTh2da03 4B8An32CWXUbAEOtVMmmY8523MqaDtUP =4qan -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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.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. 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO+pFkACgkQeiVVYja6o6NlYQCdG8Ht54cjvmL7Gyil0JjJwNTW RLUAn1A7f6Q/t4VzO+9Z5zHHJtQeCqBk =Exps -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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.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. 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. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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.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. 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. -- Thanks, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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 noarch21-0.9 rawhide 17 k firewalld-config-workstationnoarch0.3.10-4.fc21 rawhide 40 k Removing: fedora-release-server noarch21-0.9 @System1.0 k firewalld-config-server noarch0.3.10-4.fc21 @System1.0 k Transaction Summary Install 2 Packages Remove 2 Packages Total download size: 57 k Is this ok [y/N]: ... Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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 noarch21-0.9 rawhide 17 k firewalld-config-workstationnoarch 0.3.10-4.fc21 rawhide 40 k Removing: fedora-release-server noarch21-0.9 @System1.0 k firewalld-config-server noarch 0.3.10-4.fc21 @System1.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 RepositorySize Installing: fedora-release-server noarch21-0.9rawhide 17 k Removing: fedora-release-workstation noarch21-0.9installed 1.0 k Removing for dependencies: firewall-config noarch0.3.10-4.fc21 installed 778 k firewalld noarch0.3.10-4.fc21 installed 2.1 M firewalld-config-workstationnoarch0.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
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On 7 Jul 2014, at 11:17, Josh Boyer wrote: On Mon, Jul 7, 2014 at 9:02 AM, Stephen Gallagher sgall...@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? -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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 sgall...@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. This is true. 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. This is nuanced. Fedora as a non-Productized repository will exist. See below. 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. This is true. 4. 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. 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. 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? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO9qS8ACgkQeiVVYja6o6Oa3ACbBm+zSBn3I2WLRhjU35d16644 emEAnjSHRMoSOX3aGXrobm+uxzYbSfaG =e1DI -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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 -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO6mWoACgkQeiVVYja6o6PdZwCfZcnWJK6A6L3cxHzBPB776LRj f48Anj6nyCYYxuke8j6G2ouuy33evibh =fE/p -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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 sgall...@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... -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO6ml4ACgkQeiVVYja6o6PMawCeIHEM/LQ1jBHnHSwFCBLyqu4j ygoAoJiwbuS0RjmE1jeOiJ9Ulsfa6fZj =N7VT -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Mon, Jul 7, 2014 at 9:02 AM, Stephen Gallagher sgall...@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 sgall...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Thu, 2014-07-03 at 10:05 -0400, Josh Boyer wrote: On Thu, Jul 3, 2014 at 9:57 AM, Stephen Gallagher sgall...@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? -- William will...@firstyear.id.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO1YTIACgkQeiVVYja6o6OKuwCgsetv/Dr3umWKlCLvgEeqIJat i30An3NCXXVeYe6K5iEYhEWe1yPjhor0 =mBtM -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Thu, Jul 3, 2014 at 9:57 AM, Stephen Gallagher sgall...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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_. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Mon, Jun 30, 2014 at 02:59:20PM -0400, Stephen Gallagher wrote:
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.
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
--
Karel Zak k...@redhat.com
http://karelzak.blogspot.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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
--
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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 (sgall...@redhat.com) wrote: 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. 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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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? -- William will...@firstyear.id.au signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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? -- William will...@firstyear.id.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
Dne 30.6.2014 20:59, Stephen Gallagher napsal(a): 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. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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): 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. 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOyq58ACgkQeiVVYja6o6Pv8gCglKUrgDPu/PfqdVu5aqz5UNG2 IU0AnjYGe1hMpMegm4eJfYYqAmL1DYO9 =VL2o -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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): 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. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOxs4gACgkQeiVVYja6o6MtRACgm+fGmlErdjhBEXgTT+opxcTb y+wAnjyidVGBrDZFrcSd6kcex38Lj0pA =BBo7 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Mon, Jun 30, 2014 at 2:59 PM, Stephen Gallagher sgall...@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 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. 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. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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 sgall...@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 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOxur8ACgkQeiVVYja6o6NWegCfWeVE05NzFHqjkRxTmFn9xLmm 3/0An3TSLr5PSXflAq0a8WfmGflnE/dS =o5tx -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Mon, Jun 30, 2014 at 3:30 PM, Stephen Gallagher sgall...@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 sgall...@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. 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Mon, 30.06.14 14:59, Stephen Gallagher (sgall...@redhat.com) wrote: 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. 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 -- 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
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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 sgall...@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 sgall...@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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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 (sgall...@redhat.com) wrote: 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. 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOxvhkACgkQeiVVYja6o6P0tgCcDmWENFbPZp879VpGpxy2+INl tzYAn03lltlyBXN98Kz236+F8S2/vy7+ =ojNm -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOxwScACgkQeiVVYja6o6P83ACfS/MI1TYBME354LW+Zb08FIfo M94AnAiSms1F+T55/JvUu0x2nJyhGAaP =/8zd -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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 sgall...@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 sgall...@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... 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). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOxxacACgkQeiVVYja6o6MoOACbB9WcFYb2rOZfrZvXjcW+lGGC G4YAoJ5aeFwqV7O4MIDR8D2nEuQaZKY/ =BFiB -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Mon, 30.06.14 16:16, Stephen Gallagher (sgall...@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 -- 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
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-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 (sgall...@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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOxzAYACgkQeiVVYja6o6OChACeIQVHMteBGN0CZ6e0P+9614uL FLQAoJgfHzcLm1hxGto40fTDZiX/q3WJ =2sfF -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Mon, 30.06.14 16:43, Stephen Gallagher (sgall...@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 -- 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
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Jun 30, 2014, at 5:15 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 30.06.14 16:43, Stephen Gallagher (sgall...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Mon, 30.06.14 17:31, Stephen Gallagher (sgall...@redhat.com) wrote: On Jun 30, 2014, at 5:15 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 30.06.14 16:43, Stephen Gallagher (sgall...@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 -- 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
