Re: Per-Product Config file divergence
Stephen Gallagher wrote: 2) foo-config-cloud remains on the system, irrespective of the presence of fedora-release-cloud That's what's going to happen, because there's nothing that enforces that foo-config-default MUST be the one used by default. It's only preferred at install time due to being the first alternative in the or (assuming the preference algorithm really gets implemented like that), but once another foo-config-* is installed, nothing enforces a switch to -default. Kevin Kofler -- 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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2014 01:13 AM, Kevin Kofler wrote: Stephen Gallagher wrote: The primary problem is that we need to be able to address the potential for packages that *aren't* part of the default install to handle differing config based on the Product upon which it is being installed. For example, let's say that theoretically, Fedora Cloud doesn't install very many packages at all. Normal operation would be to pick and choose other packages from the repos later. We need a mechanism that says if I yum install this package onto Fedora Cloud, I should get a default that's sensible for Fedora Cloud, which might or might not be the same as is sensible for other Products. If you know about the package at GA release time, you could still drop the required config file from the live kickstart. That really wouldn't scale. While I hope the set of divergent packages would be very small, it could still in theory mean a lot of additional wasted space if we included every possible divergent config on the system. Moreover, we need to account for the possibility that any package could spontaneously decide that it should have a different default for one Product than another. We need to be able to adapt to that post-GA. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMm5l8ACgkQeiVVYja6o6P3xQCfSx2QCLEBI0l3rRPFzq1XzYAo L6kAn2Ko+o/QlLXI2/vLZAqIAzCaSyOV =NZMz -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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2014 01:16 AM, Kevin Kofler wrote: Stephen Gallagher wrote: - From what I've seen of the planned rich dependencies, I don't think they would provide any mechanism better than this one anyway. Can you explain how you would see this working, with a specific example? foo.spec: Requires: foo-config-default or foo-config-server or foo-config-cloud Requires: not fedora-release-server or foo-config-server Requires: not fedora-release-cloud or foo-config-cloud Ok, so if I'm parsing this right (my boolean logic is always on the fritz), it basically says: If fedora-release-server is installed, then install foo-config-server else if fedora-release-cloud is installed, then install foo-config-cloud else install foo-config-default (And the implication here is that fedora-release-server Conflicts with fedora-release-cloud). That's probably a reasonable approach, assuming those rich dependencies work as advertised and are available in Fedora 21. (I've heard that they're present in RPM itself, but so far the FPC has not approved any such usage. This example is probably worth raising with them.) Thank you for the explanation. The above approach is also fairly future-proof, as if we add a new Product to the line-up, that Product would just pull in foo-config-default until and unless the maintainer decided to add a new, Product-specific config sub-package. As noted above, this makes a couple implications for future usage, however: 1) If we select this route, we make it impossible to have co-tenancy of two Products (e.g. Server and Workstation). This seems to be a statement that the various groups have been circling in on, and I'm coming to see the value in making this assertion. 2) Unless I misunderstand how the dependency-resolution works, it becomes impossible to change from one Product to another (e.g. Cloud's adopt-a-server switch to Server).[1] [1] I could be wrong here; it depends on how RPM and YUM handles 'yum remove fedora-release-cloud; yum install fedora-release-server'. Lets assume that foo has foo-config-cloud installed. I see three possible outcomes to 'yum remove fedora-release-cloud': 1) foo-config-cloud is removed and foo-config-default is installed 2) foo-config-cloud remains on the system, irrespective of the presence of fedora-release-cloud 3) The transaction aborts because of unsatisfied dependencies. Similar questions are therefore inherent with 'yum install fedora-release-server' after that: do packages get the server default configs or do they remain with the cloud or default configs? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMm6gwACgkQeiVVYja6o6PeYACfeYhu2SIY8/9KRP7sXDrRnr9U 6d8AoImUXiaOZYyHOXQjHnMpjXjpjF79 =9zKP -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: Per-Product Config file divergence
On Mon, Mar 17, 2014 at 08:26:52AM -0400, Stephen Gallagher wrote: [1] I could be wrong here; it depends on how RPM and YUM handles 'yum remove fedora-release-cloud; yum install fedora-release-server'. Lets assume that foo has foo-config-cloud installed. I see three possible outcomes to 'yum remove fedora-release-cloud': 1) foo-config-cloud is removed and foo-config-default is installed 2) foo-config-cloud remains on the system, irrespective of the presence of fedora-release-cloud 3) The transaction aborts because of unsatisfied dependencies. Not sure about with DNF, but with yum we could use yum swap instead of separate remove and install commands. Worst case, we write a plugin to handle this adoption case. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- 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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/17/2014 09:13 AM, Matthew Miller wrote: On Mon, Mar 17, 2014 at 08:26:52AM -0400, Stephen Gallagher wrote: [1] I could be wrong here; it depends on how RPM and YUM handles 'yum remove fedora-release-cloud; yum install fedora-release-server'. Lets assume that foo has foo-config-cloud installed. I see three possible outcomes to 'yum remove fedora-release-cloud': 1) foo-config-cloud is removed and foo-config-default is installed 2) foo-config-cloud remains on the system, irrespective of the presence of fedora-release-cloud 3) The transaction aborts because of unsatisfied dependencies. Not sure about with DNF, but with yum we could use yum swap instead of separate remove and install commands. Hmm, you learn something new every day. I didn't know about that one. I assume it handles dependency satisfying properly? So if I did 'yum swap python-django14 python-django' it wouldn't have issues with eclipse-pydev (as a recent example I was grumbling about). Worst case, we write a plugin to handle this adoption case. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMm+scACgkQeiVVYja6o6P4NwCfeGM7x6qRzWad1SRVhIVM/x99 JhEAoIjX7EmuBLn2U6+S4TlLjmSdaiLN =5Qcx -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: Per-Product Config file divergence
Adam Williamson wrote: AIUI the installer team's opinion is more or less the precise opposite: the live installation case is problematic and if we're getting rid of anything, we should get rid of that. But AFAIK, ALL the desktop teams (the Red Hat Desktop Team working on GNOME and the SIGs working on the other desktops) recommend installing from their respective live image. Kevin Kofler -- 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: Per-Product Config file divergence
Dne 10.3.2014 17:10, Toshio Kuratomi napsal(a): At last week's FESCo meeting, the fact that Products desired to have divergent configuration was briefly touched on. On Thursday, a few FPC members had a brainstorming session about it and on Friday, sgallagh and that brainstorming continued with sgallagh, adamw, tflink, notting, and myself. We came up with a tentative idea here: https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config) The idea is to allow config file divergence via the alternatives system as that already provides us with a commandline tool and some structure to build on. We'd still have to write a few pieces to complete the picture but it seemed to be a better starting point than using rpm Conflicts between config-packages. Anyone have thoughts on this potential path? -Toshio With rich dependencies coming to Fedora, wouldn't be better to wait for a bit and benefit from them? We would have product specific configuration in subpackages and installed it such as Requires: fedora-product-cloud foo-config-cloud; Requires: fedora-product-server foo-config-server. Vít [1] https://lists.fedoraproject.org/pipermail/devel/2014-February/195743.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: Per-Product Config file divergence
On Mon, Mar 10, 2014 at 01:55:59PM -0400, Matthew Miller wrote: For cloud, the answer is start with the new image, or else okay then, you're on your own. But cloud has a big luxury of being the easy case in this regard. What about folks trying to move their server from the server product into the cloud? Matthias -- Matthias Runge mru...@matthias-runge.de -- 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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 11:27 PM, Kevin Kofler wrote: Toshio Kuratomi wrote: The idea is to allow config file divergence via the alternatives system as that already provides us with a commandline tool and some structure to build on. We'd still have to write a few pieces to complete the picture but it seemed to be a better starting point than using rpm Conflicts between config-packages. Alternatives is a horrible solution to this problem. (In fact, alternatives is a horrible solution to ANY problem it is used on.) What's wrong with just dropping the defaults in /etc in the Product's live kickstart? (Yes, that assumes the Product is delivered as a live image. We really need to do away with those non-live installers. They only cause problems and have no practical benefits.) That's how we have always set /etc/sysconfig/desktop in the KDE image: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-live-kde-base.ks#n10 Those files should then never be automatically written to again, letting the local system administrator customize the settings to his or her liking. The primary problem is that we need to be able to address the potential for packages that *aren't* part of the default install to handle differing config based on the Product upon which it is being installed. For example, let's say that theoretically, Fedora Cloud doesn't install very many packages at all. Normal operation would be to pick and choose other packages from the repos later. We need a mechanism that says if I yum install this package onto Fedora Cloud, I should get a default that's sensible for Fedora Cloud, which might or might not be the same as is sensible for other Products. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMe/mIACgkQeiVVYja6o6NYrQCghqyeXj2urLFIPijZ//nGwb4H T34AnAwyDRGt72Cek0+tyhP4HDDEruOx =Up2k -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: Per-Product Config file divergence
On Tue, Mar 11, 2014 at 10:27:12AM +0100, Matthias Runge wrote: For cloud, the answer is start with the new image, or else okay then, you're on your own. But cloud has a big luxury of being the easy case in this regard. What about folks trying to move their server from the server product into the cloud? In my thinking, Fedora Server which happens to be running in a cloud environment is Fedora Server, not Cloud. This is using a cloud provider as an overly-complicated and expensive hosting provider, which it turns out many people want to do, but it's not really cloud computing. That's the same whether you start with Fedora Cloud and take the adopt-your-cattle route, or if you start with a physical or virtual machine and migrate it. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- 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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2014 02:46 AM, Vít Ondruch wrote: Dne 10.3.2014 17:10, Toshio Kuratomi napsal(a): At last week's FESCo meeting, the fact that Products desired to have divergent configuration was briefly touched on. On Thursday, a few FPC members had a brainstorming session about it and on Friday, sgallagh and that brainstorming continued with sgallagh, adamw, tflink, notting, and myself. We came up with a tentative idea here: https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config) The idea is to allow config file divergence via the alternatives system as that already provides us with a commandline tool and some structure to build on. We'd still have to write a few pieces to complete the picture but it seemed to be a better starting point than using rpm Conflicts between config-packages. Anyone have thoughts on this potential path? -Toshio With rich dependencies coming to Fedora, wouldn't be better to wait for a bit and benefit from them? We would have product specific configuration in subpackages and installed it such as Requires: fedora-product-cloud foo-config-cloud; Requires: fedora-product-server foo-config-server. That unfortunately doesn't address the issue in a realistic way. I don't think there's a way that dependency resolution can resolve that in a positive way. The closest I can see coming up with would be: == foo == Requires: foo-config == foo-config-server == Provides: foo-config = 1.0 Conflicts: fedora-release-workstation Conflicts: fedora-release-cloud == foo-config-workstation == Provides: foo-config = 1.0 Conflicts: fedora-release-server Conflicts: fedora-release-cloud == foo-config-cloud == Provides: foo-config = 1.0 Conflicts: fedora-release-workstation Conflicts: fedora-release-server == foo-config-default == Provides: foo-config = 2.0 Conflicts: fedora-release-workstation Conflicts: fedora-release-server Conflicts: fedora-release-cloud So, if installed on a Product, yum would resolve whichever config subpackage doesn't hit any conflicts (which would be the matching version or the default, if not on a product). There are a couple down-sides to this approach: 1) It eliminates the possibility of having multiple Products installed on the same system. Whether we care about this is being debated elsewhere, but this approach would make it impossible. 2) It might make life a real pain in the neck to deal with adding new Products to Fedora, since any package providing custom authentication will have to tweak Provides: and Conflicts: to ensure that the new Product gets reasonable defaults. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMfALwACgkQeiVVYja6o6OHJACgjy0a+Db5DNj3/rCNs+FjmupO 5dkAn1RvCXAQNqdPPZx8eg8fABMZm6YK =AmCw -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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2014 09:03 AM, Vít Ondruch wrote: Dne 11.3.2014 13:25, Stephen Gallagher napsal(a): On 03/11/2014 02:46 AM, Vít Ondruch wrote: Dne 10.3.2014 17:10, Toshio Kuratomi napsal(a): At last week's FESCo meeting, the fact that Products desired to have divergent configuration was briefly touched on. On Thursday, a few FPC members had a brainstorming session about it and on Friday, sgallagh and that brainstorming continued with sgallagh, adamw, tflink, notting, and myself. We came up with a tentative idea here: https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config) The idea is to allow config file divergence via the alternatives system as that already provides us with a commandline tool and some structure to build on. We'd still have to write a few pieces to complete the picture but it seemed to be a better starting point than using rpm Conflicts between config-packages. Anyone have thoughts on this potential path? -Toshio With rich dependencies coming to Fedora, wouldn't be better to wait for a bit and benefit from them? We would have product specific configuration in subpackages and installed it such as Requires: fedora-product-cloud foo-config-cloud; Requires: fedora-product-server foo-config-server. That unfortunately doesn't address the issue in a realistic way. I don't think there's a way that dependency resolution can resolve that in a positive way. The closest I can see coming up with would be: == foo == Requires: foo-config == foo-config-server == Provides: foo-config = 1.0 Conflicts: fedora-release-workstation Conflicts: fedora-release-cloud == foo-config-workstation == Provides: foo-config = 1.0 Conflicts: fedora-release-server Conflicts: fedora-release-cloud == foo-config-cloud == Provides: foo-config = 1.0 Conflicts: fedora-release-workstation Conflicts: fedora-release-server == foo-config-default == Provides: foo-config = 2.0 Conflicts: fedora-release-workstation Conflicts: fedora-release-server Conflicts: fedora-release-cloud So, if installed on a Product, yum would resolve whichever config subpackage doesn't hit any conflicts (which would be the matching version or the default, if not on a product). There are a couple down-sides to this approach: 1) It eliminates the possibility of having multiple Products installed on the same system. Whether we care about this is being debated elsewhere, but this approach would make it impossible. 2) It might make life a real pain in the neck to deal with adding new Products to Fedora, since any package providing custom authentication will have to tweak Provides: and Conflicts: to ensure that the new Product gets reasonable defaults. You are speaking about how to achieve that in current Fedora, if I understand that correctly. I am speaking about F22, where RPM/DNF should hopefully support rich dependencies. - From what I've seen of the planned rich dependencies, I don't think they would provide any mechanism better than this one anyway. Can you explain how you would see this working, with a specific example? BTW if each package contains the same file, lets say /etc/foo.cfg, but the content of this file is different between the packages, they conflicts without explicit conflict, if I am not mistaken. File-level conflicts are expressly forbidden in Fedora, because they cannot be detected from the package metadata. You have to have the whole package downloaded to catch this. By that point, it's *really* difficult to restart the transaction and resolve the conflict. I think yum basically just fails at this point and expects you to re-run with a more detailed command-line. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMfDB0ACgkQeiVVYja6o6NqQACeNtF5zcvjdRvx9mrIW8NCfq99 2Z0AnRbz/nusUquwazY3Us0Tbv3dUlP8 =9yjM -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: Per-Product Config file divergence
On Mon, 2014-03-10 at 15:46 -0700, Adam Williamson wrote: Just for the more-public-record, I remain pretty sure this is a bad idea and don't think we should allow it. You should always be considered to be running exactly 0 or 1 Products. I think we should consider how to allow things like 'run a desktop on the Server product', but that shouldn't be conceived as 'run Workstation on Server'. I agree. We shouldn't get into the muddy areas of mixing, extending and customizing and stacking one on top of the other, before we even have a clear picture of what the different products will look like. -- 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: Per-Product Config file divergence
2014-03-10 17:10 GMT+01:00 Toshio Kuratomi a.bad...@gmail.com: At last week's FESCo meeting, the fact that Products desired to have divergent configuration was briefly touched on. On Thursday, a few FPC members had a brainstorming session about it and on Friday, sgallagh and that brainstorming continued with sgallagh, adamw, tflink, notting, and myself. Do we have *actual* use cases? Not just some package might need to, but $package needs to diverge in $config and obvious/simple approaches like comps aren't sufficient. Without such use cases, if the recommendation to use alternatives(8) stems from case 3 Want to have a single tool that can switch default configs per-package, I feel fairly confident in just rejecting that theoretical use case. (IOW, a Server would still be a Server if workstation is co-installed, and Cloud would still be using the Cloud-specific defaults if the full Server package set is installed.) (The numbered cases 1 and 2 are still necessary, but this proposal really does nothing for them besides write some code--we can always do that, not necessarily invoking alternatives(8).) 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: Per-Product Config file divergence
On Mar 10, 2014, at 10:10 AM, Toshio Kuratomi a.bad...@gmail.com wrote: At last week's FESCo meeting, the fact that Products desired to have divergent configuration was briefly touched on. On Thursday, a few FPC members had a brainstorming session about it and on Friday, sgallagh and that brainstorming continued with sgallagh, adamw, tflink, notting, and myself. We came up with a tentative idea here: https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config) The idea is to allow config file divergence via the alternatives system as that already provides us with a commandline tool and some structure to build on. We'd still have to write a few pieces to complete the picture but it seemed to be a better starting point than using rpm Conflicts between config-packages. Anyone have thoughts on this potential path? What will fedup updates of Fedora 20 look like? Would there be a flag, e.g. --product cloud/workstation/server? If not specified do we fail, or is there a default? Or is this getting too far ahead of things? Chris Murphy -- 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: Per-Product Config file divergence
On Mon, Mar 10, 2014 at 10:40:29AM -0600, Chris Murphy wrote: On Mar 10, 2014, at 10:10 AM, Toshio Kuratomi a.bad...@gmail.com wrote: At last week's FESCo meeting, the fact that Products desired to have divergent configuration was briefly touched on. On Thursday, a few FPC members had a brainstorming session about it and on Friday, sgallagh and that brainstorming continued with sgallagh, adamw, tflink, notting, and myself. We came up with a tentative idea here: https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config) The idea is to allow config file divergence via the alternatives system as that already provides us with a commandline tool and some structure to build on. We'd still have to write a few pieces to complete the picture but it seemed to be a better starting point than using rpm Conflicts between config-packages. Anyone have thoughts on this potential path? What will fedup updates of Fedora 20 look like? Would there be a flag, e.g. --product cloud/workstation/server? If not specified do we fail, or is there a default? Or is this getting too far ahead of things? The default should be whatever product was installed onto the system originally. Going from Fedora 20 to a Product in F21 is probably a one-off but I'm not sure what that should look like. I could be totally wrong but I believe that each of the Products will have their own install image. With that in mind, fedup might need a one-off bit of UI to ask which Product image you want to use. That image would then set the Product on the disk accordingly. -Toshio pgp0meK5sbc8S.pgp Description: 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: Per-Product Config file divergence
On Mon, 10 Mar 2014 10:09:43 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: What will fedup updates of Fedora 20 look like? Would there be a flag, e.g. --product cloud/workstation/server? If not specified do we fail, or is there a default? Or is this getting too far ahead of things? The default should be whatever product was installed onto the system originally. Going from Fedora 20 to a Product in F21 is probably a one-off but I'm not sure what that should look like. I could be totally wrong but I believe that each of the Products will have their own install image. With that in mind, fedup might need a one-off bit of UI to ask which Product image you want to use. That image would then set the Product on the disk accordingly. Or we could simply say that fedup doesn't upgrade from a non product to a product. You have to re-install or use a manual method to do that (some yum/dnf commands, etc). We need to consider this case also for someone who installs Fedora, but not one of the products (a spin, or a custom kickstart or whatever) who then wants to install a product. kevin signature.asc Description: 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: Per-Product Config file divergence
On Mon, Mar 10, 2014 at 11:22:30AM -0600, Kevin Fenzi wrote: The default should be whatever product was installed onto the system originally. Going from Fedora 20 to a Product in F21 is probably a one-off but I'm not sure what that should look like. I could be totally wrong but I believe that each of the Products will have their own install image. With that in mind, fedup might need a one-off bit of UI to ask which Product image you want to use. That image would then set the Product on the disk accordingly. Or we could simply say that fedup doesn't upgrade from a non product to a product. You have to re-install or use a manual method to do that (some yum/dnf commands, etc). That makes sense to me (although maybe there should be a special case for F20 - Fedora Workstation to make migration easier?). We need to consider this case also for someone who installs Fedora, but not one of the products (a spin, or a custom kickstart or whatever) who then wants to install a product. For cloud, the answer is start with the new image, or else okay then, you're on your own. But cloud has a big luxury of being the easy case in this regard. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- 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: Per-Product Config file divergence
On Mar 10, 2014 10:22 AM, Kevin Fenzi ke...@scrye.com wrote: On Mon, 10 Mar 2014 10:09:43 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: What will fedup updates of Fedora 20 look like? Would there be a flag, e.g. --product cloud/workstation/server? If not specified do we fail, or is there a default? Or is this getting too far ahead of things? The default should be whatever product was installed onto the system originally. Going from Fedora 20 to a Product in F21 is probably a one-off but I'm not sure what that should look like. I could be totally wrong but I believe that each of the Products will have their own install image. With that in mind, fedup might need a one-off bit of UI to ask which Product image you want to use. That image would then set the Product on the disk accordingly. Or we could simply say that fedup doesn't upgrade from a non product to a product. You have to re-install or use a manual method to do that (some yum/dnf commands, etc). We need to consider this case also for someone who installs Fedora, but not one of the products (a spin, or a custom kickstart or whatever) who then wants to install a product. Perhaps spins should also specify a product identifier. Maybe they could have the ability to specify an existing products' identifier if they are merely a variant set of packages top an existing product as well. -Toshio -- 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: Per-Product Config file divergence
On Mon, 10 Mar 2014 11:00:25 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: Perhaps spins should also specify a product identifier. Maybe they could have the ability to specify an existing products' identifier if they are merely a variant set of packages top an existing product as well. But they aren't products... so that would be pretty confusing. Yeah, if there was some spin built on top of workstation I assume they would just have the workstation product setup by pulling in the fedora-workstation-release and such. kevin signature.asc Description: 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: Per-Product Config file divergence
On Mon, Mar 10, 2014 at 10:09:43AM -0700, Toshio Kuratomi wrote:
What will fedup updates of Fedora 20 look like? Would there be a flag,
e.g. --product cloud/workstation/server? If not specified do we fail, or
is there a default?
The default should be whatever product was installed onto the system
originally. Going from Fedora 20 to a Product in F21 is probably a one-off
but I'm not sure what that should look like. I could be totally wrong but
I believe that each of the Products will have their own install image. With
that in mind, fedup might need a one-off bit of UI to ask which Product
image you want to use. That image would then set the Product on the disk
accordingly.
I assume that we'll do something that makes it easy to read the existing
product from the system -- I like fedora-release +
fedora-release-{workstation,server,cloud} subpackages.
And I think those subpackages probably _should_ conflict, don't you?
I guess with the new /etc/os-release format, that file could be part of the
proposed alternatives scheme, with the base package providing a default and
each of the product release files possibly updating it.
I'm not quite sure how to handle OS variants with os-release. Either put the
product/variant name in NAME and ID, (Fedora Cloud, fedora-cloud) and
ID_LIKE to specify fedora. But ID_LIKE makes very weak claims about what
like means -- it is in same general family as, not is an example of.
So, maybe it would be best to coordinate an extension to that format, so
that there are subsets to ID? (So we can have family, genus, and species...)
--
Matthew Miller-- Fedora Project--mat...@fedoraproject.org
--
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: Per-Product Config file divergence
On Mon, Mar 10, 2014 at 12:08:40PM -0600, Kevin Fenzi wrote: On Mon, 10 Mar 2014 11:00:25 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: Perhaps spins should also specify a product identifier. Maybe they could have the ability to specify an existing products' identifier if they are merely a variant set of packages top an existing product as well. But they aren't products... so that would be pretty confusing. We don't necessarily have to limit the identifier to Official Products. It's purpose is to allow software to differentiate this-thing-that-we-ship-that's-different-than-these-other-things. So it might be that spins fall into this category jsut as much as the Official Products do. Yeah, if there was some spin built on top of workstation I assume they would just have the workstation product setup by pulling in the fedora-workstation-release and such. -Toshio pgplUcG5cNk2I.pgp Description: 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: Per-Product Config file divergence
On Mar 10, 2014 11:09 AM, Matthew Miller mat...@fedoraproject.org wrote:
On Mon, Mar 10, 2014 at 10:09:43AM -0700, Toshio Kuratomi wrote:
What will fedup updates of Fedora 20 look like? Would there be a flag,
e.g. --product cloud/workstation/server? If not specified do we fail,
or
is there a default?
The default should be whatever product was installed onto the system
originally. Going from Fedora 20 to a Product in F21 is probably a
one-off
but I'm not sure what that should look like. I could be totally wrong
but
I believe that each of the Products will have their own install image.
With
that in mind, fedup might need a one-off bit of UI to ask which Product
image you want to use. That image would then set the Product on the
disk
accordingly.
I assume that we'll do something that makes it easy to read the existing
product from the system -- I like fedora-release +
fedora-release-{workstation,server,cloud} subpackages.
And I think those subpackages probably _should_ conflict, don't you?
Depends. Sgallagh had a desire to mark that a particular system
implemented multiple products (ie server that also had workstation
installed). I'm not sure that's a good idea but if we did go that route
then we'd have to be able to support that with our identifiers.
Subpackages that conflict wouldn't be flexible enough to handle that.
-Toshio
--
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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2014 02:09 PM, Matthew Miller wrote:
On Mon, Mar 10, 2014 at 10:09:43AM -0700, Toshio Kuratomi wrote:
What will fedup updates of Fedora 20 look like? Would there be
a flag, e.g. --product cloud/workstation/server? If not
specified do we fail, or is there a default?
The default should be whatever product was installed onto the
system originally. Going from Fedora 20 to a Product in F21 is
probably a one-off but I'm not sure what that should look like.
I could be totally wrong but I believe that each of the Products
will have their own install image. With that in mind, fedup
might need a one-off bit of UI to ask which Product image you
want to use. That image would then set the Product on the disk
accordingly.
I assume that we'll do something that makes it easy to read the
existing product from the system -- I like fedora-release +
fedora-release-{workstation,server,cloud} subpackages.
And I think those subpackages probably _should_ conflict, don't
you?
I would actually think that (so far as possible) we should be able to
make them capable of not conflicting.
I'd rather see us handle things this way:
fedora-release Requires: fedora-release-variant
fedora-release-$PRODUCT[1] Provides: fedora-release-variant
The first fedora-release-$PRODUCT package installed on the system sets
the base product/spin appropriately (in some well-known config file,
not necessarily /etc/os-release)
Other fedora-release-$PRODUCT packages can be installed later for the
purposes of pulling in their packages. By default, unless
- --product=$NEWPRODUCT is passed to yum, any packages they pulled in
would get the original product's alternative default config provided
(if there is one; we also need to design this mechanism so that the
assumption is that there is no difference unless specified)
My reasoning is that I think it should be easy to turn a Fedora Cloud
deployment into a Fedora Server simply with 'yum install
- --product=server fedora-release-server' and similarly that I should
potentially be able to install a graphical environment for Fedora
Server by doing 'yum install fedora-release-server-graphical'[2][3].
[1] Where $PRODUCT might be a spin identifier
[2] Where fedora-release-server-graphical might be equivalent to
fedora-release-workstation or might be a different set, depending on
how we decide to cultivate it.
[3] This particular case is weak, as if it's *not* Workstation
equivalent, we'd be more likely to treat it as a simple yum group,
since it's unlikely to need separate default configuration from the
Server.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMeCCEACgkQeiVVYja6o6O05gCePlScDpjTGExA3ruvUoseTo1L
8ZMAoJgZ6h8sAxRxJOlAKoVf1/GSLh/E
=L6EH
-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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2014 02:31 PM, Toshio Kuratomi wrote:
On Mar 10, 2014 11:09 AM, Matthew Miller
mat...@fedoraproject.org mailto:mat...@fedoraproject.org
wrote:
On Mon, Mar 10, 2014 at 10:09:43AM -0700, Toshio Kuratomi wrote:
What will fedup updates of Fedora 20 look like? Would there
be a flag, e.g. --product cloud/workstation/server? If not
specified do we
fail, or
is there a default?
The default should be whatever product was installed onto the
system originally. Going from Fedora 20 to a Product in F21 is
probably a
one-off
but I'm not sure what that should look like. I could be
totally
wrong but
I believe that each of the Products will have their own
install
image. With
that in mind, fedup might need a one-off bit of UI to ask which
Product image you want to use. That image would then set the
Product on the
disk
accordingly.
I assume that we'll do something that makes it easy to read the
existing product from the system -- I like fedora-release +
fedora-release-{workstation,server,cloud} subpackages.
And I think those subpackages probably _should_ conflict, don't
you?
Depends. Sgallagh had a desire to mark that a particular system
implemented multiple products (ie server that also had workstation
installed). I'm not sure that's a good idea but if we did go that
route then we'd have to be able to support that with our
identifiers. Subpackages that conflict wouldn't be flexible enough
to handle that.
To expand on this:
One of my goals for the Products is that their base installs should be
considered essentially a platform guarantee. If I install Fedora
Server (and /etc/fedora-release-server or some such exists on the
system) it should be a guarantee that some specific set of programming
interfaces and system services are running on that system. The same
for Workstation. (Note: this definition expressly avoids the default
configuration assumptions, since A) we expect them to be occasionally
different and B) by the nature of configuration, they are mutable and
therefore we don't want to treat configuration changed by the user in
a manner permitted by the software as no longer Fedora $PRODUCT.)
My hope here, then, is that in an ideal world, a system whose platform
guarantee provides all of Fedora Server, Fedora Cloud and Fedora
Workstation should be possible. The stealth requirement here is that
installed packages should never conflict between Products.[1]
[1] Fedora Server Roles may end up being a slightly special case, as
we're talking about possibly allowing a Server Role to force its
dependent packages to stay at a particular older version until the
complete set is tested together. But this should be a transient state
and may ultimately be resolved in an alternative packaging manner,
such as Software Collections. Thus, I'll note it here, but hope to
resolve it in a compatible manner.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMeCW8ACgkQeiVVYja6o6NIuQCcC+9CDClCFFMmhVmF2Kve8oCr
NAUAnA0nm/lms22x1inXfFI7d4dxJYnm
=yjAe
-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: Per-Product Config file divergence
On 03/10/2014 12:44 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd rather see us handle things this way: fedora-release Requires: fedora-release-variant fedora-release-$PRODUCT[1] Provides: fedora-release-variant The first fedora-release-$PRODUCT package installed on the system sets the base product/spin appropriately (in some well-known config file, not necessarily /etc/os-release) but what happens with the people using kickstarts to install Fedora, by example I'm using kickstarts to install the following - @core @standard groups and 5 to 10 specific rpms (bind, lighttpd, postfix) - @core @base-x @virtualization and a list of 300 rpms packages so will be required to install a product (fedora-release-variant) and by consequence add more rpms to my kickstarts installs? thanks, Gabrielo -- 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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 03:25 PM, Gabriel Ramirez wrote: On 03/10/2014 12:44 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd rather see us handle things this way: fedora-release Requires: fedora-release-variant fedora-release-$PRODUCT[1] Provides: fedora-release-variant The first fedora-release-$PRODUCT package installed on the system sets the base product/spin appropriately (in some well-known config file, not necessarily /etc/os-release) but what happens with the people using kickstarts to install Fedora, by example I'm using kickstarts to install the following - @core @standard groups and 5 to 10 specific rpms (bind, lighttpd, postfix) - @core @base-x @virtualization and a list of 300 rpms packages so will be required to install a product (fedora-release-variant) and by consequence add more rpms to my kickstarts installs? You misunderstand. This is if a package requires a choice, it will provide a default and this can be explicitly changed by passing - --product=something. If you DO have a Product installed, it will treat all yum commands as including --product=something unless you specify it otherwise. The default case (if no Product is installed) must be addressed. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMeFZYACgkQeiVVYja6o6OAaACeKzp7DKK5YgxqWFf7smOnDKri zR4AoKcRixEIvliUM17pMA0UBtEqSxX6 =JWAR -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: Per-Product Config file divergence
On Mon, Mar 10, 2014 at 6:22 PM, Kevin Fenzi ke...@scrye.com wrote: On Mon, 10 Mar 2014 10:09:43 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: What will fedup updates of Fedora 20 look like? Would there be a flag, e.g. --product cloud/workstation/server? If not specified do we fail, or is there a default? Or is this getting too far ahead of things? The default should be whatever product was installed onto the system originally. Going from Fedora 20 to a Product in F21 is probably a one-off but I'm not sure what that should look like. I could be totally wrong but I believe that each of the Products will have their own install image. With that in mind, fedup might need a one-off bit of UI to ask which Product image you want to use. That image would then set the Product on the disk accordingly. Or we could simply say that fedup doesn't upgrade from a non product to a product. You have to re-install or use a manual method to do that (some yum/dnf commands, etc). We shouldn't make things harder for users to make it easier for us .. that's backwards. -- 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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 03:58 PM, drago01 wrote: On Mon, Mar 10, 2014 at 6:22 PM, Kevin Fenzi ke...@scrye.com wrote: On Mon, 10 Mar 2014 10:09:43 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: What will fedup updates of Fedora 20 look like? Would there be a flag, e.g. --product cloud/workstation/server? If not specified do we fail, or is there a default? Or is this getting too far ahead of things? The default should be whatever product was installed onto the system originally. Going from Fedora 20 to a Product in F21 is probably a one-off but I'm not sure what that should look like. I could be totally wrong but I believe that each of the Products will have their own install image. With that in mind, fedup might need a one-off bit of UI to ask which Product image you want to use. That image would then set the Product on the disk accordingly. Or we could simply say that fedup doesn't upgrade from a non product to a product. You have to re-install or use a manual method to do that (some yum/dnf commands, etc). We shouldn't make things harder for users to make it easier for us .. that's backwards. Yeah, we really need packages to have a true default (which is used if no Product is specified) and then may have other Product-specific defaults. In one of my other responses to this thread, I postulated a straw-man solution for this. Feel free to bring torches :) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMeG3QACgkQeiVVYja6o6MSDQCghZS7sLjBtgZ4IUK9/cT0GYmf mJ8An0HGGYW30S4GoccOfDNiTngfb9iI =fl2X -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: Per-Product Config file divergence
On Mon, Mar 10, 2014 at 03:16:31PM -0400, Martin Langhoff wrote: On Mon, Mar 10, 2014 at 12:10 PM, Toshio Kuratomi a.bad...@gmail.com wrote: The idea is to allow config file divergence via the alternatives system as Will this handle user customization? IME alternatives is not geared to handle config files, customizable shell scripts, etc. That's an issue that I was trying to think through over the weekend. I think you're right that alternatives by itself wouldn't handle this well. I was trying to figure out if we could use alternatives to copy in a config file instead of symlinking or check the hash of the file just like rpm would do with any other config file but didn't get through my thought experiments. It may be that vanilla alternatives is unsuitable but we want something alternatives-like (an external tool that updates the config file) rather than something based on rpm metadata (Conflicts which causes you to have either one or the other package installed). -Toshio pgpZ8XQJw1fNS.pgp Description: 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: Per-Product Config file divergence
My reasoning is that I think it should be easy to turn a Fedora Cloud deployment into a Fedora Server I'd like to see a concrete driver for that goal. I mean, how would that be different than installing the role infrastructure? The overlap between Server and Cloud is an interesting topic but realistically - aren't we just talking about some different defaults (e.g. Cloud needs metadata services like cloud-init/min-metadata-service, which are a bit dangerous on bare metal), potentially different filesystem defaults, etc... And I don't think anyone who would be turning Cloud into Server would want their metadata service to be disabled, and obviously we can't change their filesystem... So ultimately what use case isn't covered by just changing the package set? I should potentially be able to install a graphical environment for Fedora Server by doing 'yum install fedora-release-server-graphical'[2][3]. Now this one I definitely agree with. Specifically that it should be -server-graphical and not merely installing the -workstation release. -- 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: Per-Product Config file divergence
On Mon, Mar 10, 2014 at 3:56 PM, Stephen Gallagher sgall...@redhat.com wrote: 2) If we allow switching between products, we probably have to treat the entire Product configuration of a package as a single unit. ok. Edits to somefile.conf would change whatever's on the other end of the link. The alternatives system would change this linkage, to another version, but switching it back will give you your edits, not just the original defaults. If this is what we do, then the target of that link must be marked in the rpm packages as %conf, regardless of where it resides. For an approach like this, which I'm not yet sure I like, I'd consider putting some effort on improving alternatives. It's never been used for editable targets afaict. cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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: Per-Product Config file divergence
On Mon, Mar 10, 2014 at 4:30 PM, Toshio Kuratomi a.bad...@gmail.com wrote: It may be that vanilla alternatives is unsuitable but we want something alternatives-like (an external tool that updates the config file) rather than something based on rpm metadata (Conflicts which causes you to have either one or the other package installed). Yep, that's exactly my thinking. Hard to think through the scenarios without some concrete examples. Is there a listing of concrete use-cases? i.e.: server configuration with a paranoid settings for sshd_conf / sudoers / securetty , vs more liberal desktop config? m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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: Per-Product Config file divergence
On 03/10/2014 06:55 PM, Matthew Miller wrote: That makes sense to me (although maybe there should be a special case for F20 - Fedora Workstation to make migration easier?). A close enough heuristic should be to look if the user has gnome-shell installed and install the Workstation config package in that case. This should be easily doable with obsoletes, e.g. adding Obsoletes: gnome-shell 3.14 to both gnome-shell and the new Workstation config package. This would cause yum to pull in BOTH packages when updating gnome-shell. -- 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: Per-Product Config file divergence
On Mon, 2014-03-10 at 11:31 -0700, Toshio Kuratomi wrote: And I think those subpackages probably _should_ conflict, don't you? Depends. Sgallagh had a desire to mark that a particular system implemented multiple products (ie server that also had workstation installed). I'm not sure that's a good idea but if we did go that route then we'd have to be able to support that with our identifiers. Subpackages that conflict wouldn't be flexible enough to handle that. Just for the more-public-record, I remain pretty sure this is a bad idea and don't think we should allow it. You should always be considered to be running exactly 0 or 1 Products. I think we should consider how to allow things like 'run a desktop on the Server product', but that shouldn't be conceived as 'run Workstation on Server'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Per-Product Config file divergence
On 10 March 2014 16:46, Adam Williamson awill...@redhat.com wrote: On Mon, 2014-03-10 at 11:31 -0700, Toshio Kuratomi wrote: And I think those subpackages probably _should_ conflict, don't you? Depends. Sgallagh had a desire to mark that a particular system implemented multiple products (ie server that also had workstation installed). I'm not sure that's a good idea but if we did go that route then we'd have to be able to support that with our identifiers. Subpackages that conflict wouldn't be flexible enough to handle that. Just for the more-public-record, I remain pretty sure this is a bad idea and don't think we should allow it. You should always be considered to be running exactly 0 or 1 Products. I think we should consider how to allow things like 'run a desktop on the Server product', but that shouldn't be conceived as 'run Workstation on Server'. As a Smoke Jumper Sysadmin, I agree 100% with Adam. I have spent too many projects/problems/criseses dealing with combinatorics because someone has enabled X with Y with Z with X because they could. If there is one long train of woes, catastrophe, and doom it is where people take limited things and then try to get them to combine. Because you will quickly find ARM+Cloud+Server+Desktop and then realizing that it is completely different from Server+Desktop+Cloud+ARM in how it works. (etc etc). Either have them run 0 products and get to combine everything they want (eg make their own product), or have them run a product and get a tailored environment known to fix problem ABC. Trying to be more complex than that is not going to solve any problems worth solving in the time we have to solve them. -- Stephen J Smoogen. -- 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: Per-Product Config file divergence
On Mon, 2014-03-10 at 13:25 -0600, Gabriel Ramirez wrote: On 03/10/2014 12:44 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd rather see us handle things this way: fedora-release Requires: fedora-release-variant fedora-release-$PRODUCT[1] Provides: fedora-release-variant The first fedora-release-$PRODUCT package installed on the system sets the base product/spin appropriately (in some well-known config file, not necessarily /etc/os-release) but what happens with the people using kickstarts to install Fedora, by example I'm using kickstarts to install the following - @core @standard groups and 5 to 10 specific rpms (bind, lighttpd, postfix) - @core @base-x @virtualization and a list of 300 rpms packages so will be required to install a product (fedora-release-variant) and by consequence add more rpms to my kickstarts installs? No. You aren't required to run a Product to use Fedora. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Stephen Gallagher wrote: /etc/somefile.conf is a [soft|hard]link that points to one of: /etc/packagename.conf/default/somefile.conf /etc/packagename.conf/cloud/somefile.conf /etc/packagename.conf/server/somefile.conf /etc/packagename.conf/workstation/somefile.conf Edits to somefile.conf would change whatever's on the other end of the link. The alternatives system would change this linkage, to another version, but switching it back will give you your edits, not just the original defaults. I would prefer to have that mechanism under /usr/share, owned by RPM and untouched by admins, and then a single /etc/somefile.conf, empty by default (or with only comments) where admins can override the parameters they need to, and only those. Then the admin's overrides would remain effective when the link is changed. But then the program that is to read the configuration file must be able to handle such a setup. Björn Persson -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJTHlzFAAoJEOE4WtzWSuY/TA0P/0qaZ52Z3ZyZ0xn/+H+DRCOl SPaFT2h8asuDgn/NooHbfU1KYdyaTmsJgGmSbk50e0nko8uRkzwlWZc7OxHUNU0Q P63Ml0iIBJVFHFAXnt7MpU7AvCdX3wsm9V10JHGts539k9mHmP/r2GlkUn11n3RG cVdMFGRPAydmfX6WRoxNjpBEgPJCG2T1eBwv7M8O0E8r/uhLlarCMVzkfTCqkYG4 cZ7k48kJ/FVPTrt/SMsDgXr9wYp3sdxKL0xnMpaXsc9lsqB4t5BqIJwsfbkK9qkp V4xcLKD2zM1wbDL2aTqgDgXC5kFSxJZcXaY0JEVMRED0C+bJaqva8yJ/IGm4XE3b Fovjc+JR3DHUHcSmc2/Cbsasf/6HcB5we5FP68U4owAdBFNnnGjVTFth0mEjcfnD RnQv3K7pW7GkjWhTJkmQ8xou+D081jlTRMI3GkWx0gAbyDNCFdWwaMmHaB5QaitS 9yNJ3aoohd9fe3DhyC7W3WWl1PbVV60M0y51ruJMh0qPT5m5yPHLgtBCHsINqnhr gN16VcbKYYv5IpWc5/3D/zPp4HVUmU4O6vl+agSzZhI1hyf/y7REj0vt311quDPK QulUdyo++Gp8+hexS7vY5mnyYVGTR6Vp+rCAsv8CmXxOipBaAuJiKaqNKaCUp0Vz 2emHNqVrMSu/WFLshORW =kp2a -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: Per-Product Config file divergence
Toshio Kuratomi (a.bad...@gmail.com) said: At last week's FESCo meeting, the fact that Products desired to have divergent configuration was briefly touched on. On Thursday, a few FPC members had a brainstorming session about it and on Friday, sgallagh and that brainstorming continued with sgallagh, adamw, tflink, notting, and myself. We came up with a tentative idea here: Well, I read a couple hours of backscroll and made two comments; I don't really think that qualifies me as a co-author. That being said... https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config) The idea is to allow config file divergence via the alternatives system as that already provides us with a commandline tool and some structure to build on. We'd still have to write a few pieces to complete the picture but it seemed to be a better starting point than using rpm Conflicts between config-packages. ... I'm not really convinced that alternatives is the way to go here. For one, it's implemented as symlink farms; depending on how tools modify configuration, that can cause problematic/unpredictable drift. Stepping back, if you allow this, in general, you get the following potential bifurcation for any one product: a) the default config when in Server b) the default config when in Cloud c) the default config when in Workstation d) the default config when in spin XYZ ... z) the default config when in none of the above etc. I'm struggling to think of a viable case where we want users to be able to pick any of the above for a package running on any other of the above. It would seem simplest to me that for any package, you either get the config for your particular product that you have installed, or you get z) if it doesn't have one for your product. Among other things, this simplifies the test matrix. Bill -- 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: Per-Product Config file divergence
Toshio Kuratomi wrote: The idea is to allow config file divergence via the alternatives system as that already provides us with a commandline tool and some structure to build on. We'd still have to write a few pieces to complete the picture but it seemed to be a better starting point than using rpm Conflicts between config-packages. Alternatives is a horrible solution to this problem. (In fact, alternatives is a horrible solution to ANY problem it is used on.) What's wrong with just dropping the defaults in /etc in the Product's live kickstart? (Yes, that assumes the Product is delivered as a live image. We really need to do away with those non-live installers. They only cause problems and have no practical benefits.) That's how we have always set /etc/sysconfig/desktop in the KDE image: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-live-kde-base.ks#n10 Those files should then never be automatically written to again, letting the local system administrator customize the settings to his or her liking. Kevin Kofler -- 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: Per-Product Config file divergence
On Tue, 2014-03-11 at 04:27 +0100, Kevin Kofler wrote: Toshio Kuratomi wrote: The idea is to allow config file divergence via the alternatives system as that already provides us with a commandline tool and some structure to build on. We'd still have to write a few pieces to complete the picture but it seemed to be a better starting point than using rpm Conflicts between config-packages. Alternatives is a horrible solution to this problem. (In fact, alternatives is a horrible solution to ANY problem it is used on.) What's wrong with just dropping the defaults in /etc in the Product's live kickstart? (Yes, that assumes the Product is delivered as a live image. We really need to do away with those non-live installers. They only cause problems and have no practical benefits.) AIUI the installer team's opinion is more or less the precise opposite: the live installation case is problematic and if we're getting rid of anything, we should get rid of that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Per-Product Config file divergence
On Mon, Mar 10, 2014 at 11:27 PM, Kevin Kofler kevin.kof...@chello.at wrote: What's wrong with just dropping the defaults in /etc in the Product's live kickstart? (Yes, that assumes the Product is delivered as a live image. We For server images, Live isn't so hot. Can anaconda be taught to execute a %product Foo kickstart file section? cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
