Re: How to handle upgrades to Fedora 21
On 10/01/2014 10:28 PM, Stephen Gallagher wrote: Fedora officially only supports upgrades from a*fully-upgraded Fedora* to the next version, so we could work around this by adding a temporary explicit Requires: fedora-release-standard on the F20 fedora-release package, thereby forcing all upgrades to be non-productized. This is my recommended approach as it requires only a single change (the added Requires:) to fedora-release to make it work. The end-result of this I tried the upgrade during weekend. And I tried to simulate this requires during upgrade. The problem is that once you get fedora-release-standard, you will get other *-standard (e.g. firewalld-config-standard) and there is no way to switch -workstation (or other product) unless you use 'rpm --nodeps', which is pretty dirty hack. If you use this Requires, then at the same time please provide users migration tool product2product. Or at least standard2product. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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: How to handle upgrades to Fedora 21
On 10/03/2014 10:57 PM, Stephen Gallagher wrote: To that end, fedup will grow a new mandatory option: --product. It will take one of four arguments: standard (non-productized), server, workstation or cloud. For those rebels who use fedora-upgrade(8): this script now ask you right after distro-sync, which product you want to choose or if you want to stay on -standard version. Available since fedora-upgrade-21.2-1.fc20 Enjoy and report problems -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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: How to handle upgrades to Fedora 21
Hi On Mon, Oct 6, 2014 at 3:18 AM, Miroslav Suchý msu...@redhat.com wrote: I tried the upgrade during weekend. And I tried to simulate this requires during upgrade. The problem is that once you get fedora-release-standard, you will get other *-standard (e.g. firewalld-config-standard) and there is no way to switch -workstation (or other product) unless you use 'rpm --nodeps', which is pretty dirty hack. No. You can use yum swap or dnf --allowerasing Rahul -- 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: How to handle upgrades to Fedora 21
On Sat, 2014-10-04 at 12:46 -0400, Mike Pinkerton wrote: On 3 Oct 2014, at 19:37, Ray Strode wrote: I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard: 1) fedora-release-nonstandard 2) fedora-release-custom 3) fedora-release-diy 4) fedora-release-noncompliant The nonstandard and noncompliant names seem a bit pejorative. However, fedora-release-custom and fedora-release-diy (do-it- yourself) and fedora-release-pyop (pick-your-own-packageset) and fedora-release-byob (bring-your-own-blueprint) all have similar meanings to this US-English speaker, and all seem like reasonable choices, although the last three might require a parenthetical explanation for some folk. Rehashing the conversation elsewhere, the problem with DIY and similar is that it doesn't make much sense in the context of Spins, which are non-productized but not particularly do-it-yourself. Perhaps we should have just gone with 'fedora-release-nonproduct' like I originally suggested months ago... Anyway, I don't really care what we pick, so long as it's decided in the next 24 hours so we can deal with the Obsoletes hoops and make sure it gets pushed out and into a test compose. 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: How to handle upgrades to Fedora 21
Stephen Gallagher (sgall...@redhat.com) said: Rehashing the conversation elsewhere, the problem with DIY and similar is that it doesn't make much sense in the context of Spins, which are non-productized but not particularly do-it-yourself. While they're not DIY in the context of the initial install, they're not going to get the 'always get the latest version of the $PRODUCT features' that fedup and the assocated infrastructure may enforce for actual products (unless I missed something?). This means that they're likely to have more and more drift from the initial spin as time goes on, leaving them in a more custom state. 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: How to handle upgrades to Fedora 21
On Sat, Oct 4, 2014 at 1:27 AM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Oct 03, 2014 at 06:18:11PM -0500, Michael Catanzaro wrote: I agree with Rahul that standard is not a great name for the nonstandard, non-productized upgrade, though. Generic is more descriptive anyway. But vanilla is the most delicious. But has no meaning that context for pretty much all non english languages. -- 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: How to handle upgrades to Fedora 21
On 10/03/2014 07:37 PM, Ray Strode wrote: Hi, I agree with Rahul that standard is not a great name for the nonstandard, non-productized upgrade, though. Generic is more descriptive anyway. I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard: 1) fedora-release-nonstandard 2) fedora-release-custom 3) fedora-release-diy 4) fedora-release-noncompliant and i'll just throw another out there now 5) fedora-release-respin If we do want to change it, it should happen soon --Ray To me, nonstandard has more meaning that standard and diy or noncompliant are meaningless. However, custom can be understood and has a meaning: the user has specifically tailored the package set for this system. Just saying ... Gene -- 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: How to handle upgrades to Fedora 21
On Fri, 2014-10-03 at 19:37 -0400, Ray Strode wrote: I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard: 1) fedora-release-nonstandard That this was the first item on the list suggests that fedora-release-standard is not the right name. :) In fact, most of the names on your list are antonyms of standard. 3) fedora-release-diy Not a good name for spins. This sounds like Gentoo. 4) fedora-release-noncompliant This one makes it sound like not running a product is a bad thing. Let's avoid this one. All the other names are fine. I still like fedora-release-generic the best. My favorite color of paint is Myrtle Green. It's a nice color. [1] Michael [1] https://en.wikipedia.org/wiki/Shades_of_green#Myrtle_green 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: How to handle upgrades to Fedora 21
Reindl Harald writes: Am 03.10.2014 um 23:57 schrieb Rahul Sundaram: On Fri, Oct 3, 2014 at 5:38 PM, Reindl Harald wrote: generic is technical speak or for normal people outside IT at best has a negative context to generica and spam I never heared about „generica” and seing the term „generic” I don't have any associations with spam. - standard for the ordinary user means not specialized so likely the best decision for me Exactly the message Fedora doesn't want to send to its users. Thanks for confirming +1 why? not specialized means i can likely do anything i want with that and is true it is the exactly right message for any user which has no clue what the products may mean for him or if he is unsure which one is the best - so in doubt just use standard and later install whatever you need as all the years before is the correct decision why would you try to force somebody to a prodcut setup if he can't give you an answer to the question which? From my understanding and impression the approach Fedora had so far is exactly opposite to what you are describing now. The „standard” and „default” was a full desktop with Gnome. And the „install minimal whatever, and decide later what to do” has always been a „custom” / „minimal” installation. Calling it now „standard” is indeed confusing. Especially for user which has no clue. „Standard” should be something *well* defined. Not a „whatever” configuration different for each user. Personally I don't care, but thinking about newcomers and less experienced users, I'd strongly vote for changing the name „standard” to something different if it is not too late. -- jaroslav pgprEHhouj6Fu.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: How to handle upgrades to Fedora 21
Am 04.10.2014 um 18:08 schrieb Jaroslav Nahorny: Am 03.10.2014 um 23:57 schrieb Rahul Sundaram: On Fri, Oct 3, 2014 at 5:38 PM, Reindl Harald wrote: generic is technical speak or for normal people outside IT at best has a negative context to generica and spam I never heared about „generica” and seing the term „generic” I don't have any associations with spam https://www.google.com/search?q=spam+generic+viagra there is even a SpamAssassin tag DRUG_ED_GENERIC signature.asc Description: OpenPGP digital 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: How to handle upgrades to Fedora 21
On Sat, Oct 04, 2014 at 11:56:41AM +0200, drago01 wrote: I agree with Rahul that standard is not a great name for the nonstandard, non-productized upgrade, though. Generic is more descriptive anyway. But vanilla is the most delicious. But has no meaning that context for pretty much all non english languages. True, but it's a very well established idiom in English, and it's worth noting that for trademark reasons we won't be translating any of the Cloud, Server, Workstation names, either. Anyway, it's just the color of paint _I_ would choose. -- 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: How to handle upgrades to Fedora 21
On 3 Oct 2014, at 19:37, Ray Strode wrote: I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard: 1) fedora-release-nonstandard 2) fedora-release-custom 3) fedora-release-diy 4) fedora-release-noncompliant The nonstandard and noncompliant names seem a bit pejorative. However, fedora-release-custom and fedora-release-diy (do-it- yourself) and fedora-release-pyop (pick-your-own-packageset) and fedora-release-byob (bring-your-own-blueprint) all have similar meanings to this US-English speaker, and all seem like reasonable choices, although the last three might require a parenthetical explanation for some folk. Yes, Myrtle Green would make a nice color for the bike shed. -- 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: How to handle upgrades to Fedora 21
On Wed, Oct 01, 2014 at 04:28:22PM -0400, Stephen Gallagher wrote: The thing to note is that in all scenarios, the user *MUST* fully update their F20 system first, or the results will be undefined and could be unpleasant. We need to spell this out very clearly to our upgrading users. Here's what I'm thinking... Converting from vanilla to and from productized Fedora is a separate issue from upgrading. It's something that someone might want to do at any point, and it's something that we'll want to have beyond just the F21 release. I can see the convenience value of letting people check a box or give a flag at the F20-F21 upgrade point. I wish we had thought of that several months ago, but I don't think anyone did (or we dropped it if it were mentioned, sadly). At this point, since the fedup maintainers aren't sold and we're working on validating the beta already, *and* because the upgrade-to-convert situation is a one time thing, I think we should put our efforts into the convert-at-any-time situation. -- 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: How to handle upgrades to Fedora 21
On Fri, 2014-10-03 at 12:37 -0400, Matthew Miller wrote: On Wed, Oct 01, 2014 at 04:28:22PM -0400, Stephen Gallagher wrote: The thing to note is that in all scenarios, the user *MUST* fully update their F20 system first, or the results will be undefined and could be unpleasant. We need to spell this out very clearly to our upgrading users. Here's what I'm thinking... Converting from vanilla to and from productized Fedora is a separate issue from upgrading. It's something that someone might want to do at any point, and it's something that we'll want to have beyond just the F21 release. Are arbitrary inter-product conversions supportable long-term? We can test if a default install of F20 converts into a reasonable approximation of Fedora Workstation 21. But are we going test that a F23 Workstation converts properly to a F23 Server? I can see the convenience value of letting people check a box or give a flag at the F20-F21 upgrade point. I wish we had thought of that several months ago, but I don't think anyone did (or we dropped it if it were mentioned, sadly). At this point, since the fedup maintainers aren't sold and we're working on validating the beta already, *and* because the upgrade-to-convert situation is a one time thing, I think we should put our efforts into the convert-at-any-time situation. I don't see it as a convenience value - rather it's our main point of control make sure that everybody who wants to be on a product line actually ends up on a product line. As an example: this subject came up on the workstation mailing list because there was a proposal to make the network login functionality in Fedora 21 a package that is pulled in by fedora-release-workstation rather than gnome-shell. If we carry through with that (probably depends on the result of this discussion), then people who upgraded to non-productized F21 would be missing one of the most useful new features in Fedora 21 workstation. But that's just one example of how a non-productized Fedora is not what we're advertising. With subsequent releases of Fedora the gap will grow - but *now* is the best time to make people pick a product if they want one. We could compensate a bit for lack of the feature by making fedup put up a big warning message that directed people to a wiki page with manual instructions - I don't think it looks professional, but it would be better than nothing. - Owen -- 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: How to handle upgrades to Fedora 21
On Wed, 2014-10-01 at 16:28 -0400, Stephen Gallagher wrote: On Wed, 2014-09-24 at 12:16 -0400, Stephen Gallagher wrote: There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: 1) Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. I've had a number of conversations with the yum/dnf and fedup people over the last week. The tl;dr version: option 1) is the only realistic option. So, a bit more contributing detail: First, the Products have both a minimal set and a default set of functionality that they want to have exposed if that Product is installed. What we've decided that this means is that, barring explicit influence, anyone who is installing Fedora Workstation or Fedora Server should be getting the default set of functionality and can later (or in a kickstart file) trim it back. Without changing the fedup package in Fedora, we could do upgrades to each of the Products or non-productized versions by providing on F20 a do-nothing fedora-release-[standard|cloud|server|workstation] file that in F21 has explicit requirements on any of the packages necessary to reach the minimal set of functionality. We can't force it to the default set (without allowing RPM soft dependencies, which is not currently supported or well-tested in Fedora), so upgrading through this path wouldn't guarantee the preferred result state (particularly for Workstation, which wants to have a certain set of common applications installed by default). Furthermore, it makes the upgrade process more complicated because it would require the user to manually install 'fedora-release-standard' in order to get the non-productized experience and they would not be able to upgrade *at all* without selecting one of them. Fedora officially only supports upgrades from a *fully-upgraded Fedora* to the next version, so we could work around this by adding a temporary explicit Requires: fedora-release-standard on the F20 fedora-release package, thereby forcing all upgrades to be non-productized. This is my recommended approach as it requires only a single change (the added Requires:) to fedora-release to make it work. The end-result of this upgrade is a system that is just a newer version of whatever DIY set of packages the previously-F20 system was running. It's also possible that we could rig up a selectable approach by creating a full set of empty fedora-release-* packages and arranging it so that fedora-release-standard satisfied the upgrade requirement if it wasn't specified, but this requires us to make sure that the automatic dependency-resolution for all of yum, dnf, gnome-software, yumex and apper all selects the correct default. I know for a fact that at least yum and dnf follow different resolution patterns, so while it could be possible, it would be a nasty hack relying on internal knowledge of the tools. That seems somewhat fragile to me, but it could be done if we strongly want it. The thing to note is that in all scenarios, the user *MUST* fully update their F20 system first, or the results will be undefined and could be unpleasant. We need to spell this out very clearly to our upgrading users. Yet one more change. A number of folks from the Workstation, Server and fedup teams got together in #fedora-workstation today and hashed out a new plan. We decided that it was fine to modify fedup and that it was also acceptable to force the user to make a choice at upgrade time. To that end, fedup will grow a new mandatory option: --product. It will take one of four arguments: standard (non-productized), server, workstation or cloud. For each of the Products, fedup will inject the appropriate set of packages necessary to make the resulting system contain a superset of the packages that one would get with a default installation of the selected Product. (In a technical sense, it would essentially be injecting @^$PRODUCT-product-environment onto the yum installation command to ensure that all of those packages are part of the transaction). I have sent an email to the QA folks to get this arrangement added to the Beta Criteria, since that's our last chance to realistically test upgrades before release. So fixing this becomes a blocker to Beta. 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: How to handle upgrades to Fedora 21
On Fri, 2014-10-03 at 16:57 -0400, Stephen Gallagher wrote: To that end, fedup will grow a new mandatory option: --product. It will take one of four arguments: standard (non-productized), server, workstation or cloud. I volunteered to come up with the text if you dont' specify --product. An initial draft follows: - This installation of Fedora does not belong to a product, so you must provide the --product=PRODUCTNAME option to specify what product you want to upgrade to. PRODUCTNAME should be one of: workstation: the default Fedora experience for laptops and desktops server: the default Fedora experience for servers cloud: a base image for use on public and private clouds standard: choose this if none of the above apply; in particular choose this if you are using an alternate-desktop spin of Fedora See https://fedoraproject.org/wiki/Upgrading for more information. --- Feedback from this wide audience appreciated. Would you know what option to pick? Thanks, Owen -- 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: How to handle upgrades to Fedora 21
Hi On Fri, Oct 3, 2014 at 4:57 PM, Stephen Gallagher wrote: To that end, fedup will grow a new mandatory option: --product. It will take one of four arguments: standard (non-productized), server, workstation or cloud. When the discussion about the standard name came up earlier in fedora desktop list, one counter point was that standard isn't going to be very visible to users but if you are going to use that term in fedup, it becomes even more visible. Do you still want to not use generic here? Rahul -- 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: How to handle upgrades to Fedora 21
Am 03.10.2014 um 23:12 schrieb Rahul Sundaram: On Fri, Oct 3, 2014 at 4:57 PM, Stephen Gallagher wrote: To that end, fedup will grow a new mandatory option: --product. It will take one of four arguments: standard (non-productized), server, workstation or cloud. When the discussion about the standard name came up earlier in fedora desktop list, one counter point was that standard isn't going to be very visible to users but if you are going to use that term in fedup, it becomes even more visible. Do you still want to not use generic here? generic is technical speak or for normal people outside IT at best has a negative context to generica and spam - standard for the ordinary user means not specialized so likely the best decision for me well, that may be somehow different in native english countries signature.asc Description: OpenPGP digital 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: How to handle upgrades to Fedora 21
Hi On Fri, Oct 3, 2014 at 5:38 PM, Reindl Harald wrote: generic is technical speak or for normal people outside IT at best has a negative context to generica and spam It is not really technical. Generic is often used in other contexts by normal people: Ex: Generic drugs which means non branded. - standard for the ordinary user means not specialized so likely the best decision for me Exactly the message Fedora doesn't want to send to its users. Thanks for confirming. Rahul -- 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: How to handle upgrades to Fedora 21
Am 03.10.2014 um 23:57 schrieb Rahul Sundaram: On Fri, Oct 3, 2014 at 5:38 PM, Reindl Harald wrote: generic is technical speak or for normal people outside IT at best has a negative context to generica and spam It is not really technical. Generic is often used in other contexts by normal people: Ex: Generic drugs which means non branded. generic drugs is the one thing nobody wants to have in context honestly - standard for the ordinary user means not specialized so likely the best decision for me Exactly the message Fedora doesn't want to send to its users. Thanks for confirming why? not specialized means i can likely do anything i want with that and is true it is the exactly right message for any user which has no clue what the products may mean for him or if he is unsure which one is the best - so in doubt just use standard and later install whatever you need as all the years before is the correct decision why would you try to force somebody to a prodcut setup if he can't give you an answer to the question which? signature.asc Description: OpenPGP digital 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: How to handle upgrades to Fedora 21
Hi On Fri, Oct 3, 2014 at 6:15 PM, Reindl Harald wrote: generic drugs is the one thing nobody wants to have in context honestly Not true but irrelevant anyway since I was just pointing out that generic is not a technical term. why would you try to force somebody to a prodcut setup if he can't give you an answer to the question which? Noone is forcing anything since non productized variants are continued to be supported but the emphasis is on the products (whether you think it should be is a different discussion) and as you confirmed, the use of the term standard doesn't convey that to the user Rahul -- 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: How to handle upgrades to Fedora 21
Am 04.10.2014 um 00:29 schrieb Rahul Sundaram: On Fri, Oct 3, 2014 at 6:15 PM, Reindl Harald wrote: generic drugs is the one thing nobody wants to have in context honestly Not true but irrelevant anyway since I was just pointing out that generic is not a technical term. why would you try to force somebody to a prodcut setup if he can't give you an answer to the question which? Noone is forcing anything since non productized variants are continued to be supported but the emphasis is on the products (whether you think it should be is a different discussion) and as you confirmed, the use of the term standard doesn't convey that to the user and *because* non productized variants are continued there should be no emphasis instead *equal options* - the products make sense for a user who can answer within 5 seconds sitting in front of the option to chose the question which one is the best for him i bet many can't because they would need multiple choice signature.asc Description: OpenPGP digital 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: How to handle upgrades to Fedora 21
Hi On Fri, Oct 3, 2014 at 6:34 PM, Reindl Harald wrote: and *because* non productized variants are continued there should be no emphasis instead *equal options* Fedora as a project has already discussed that extensively and decided otherwise. We are not really revisiting that discussion here. Rahul -- 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: How to handle upgrades to Fedora 21
On Fri, 2014-10-03 at 17:06 -0400, Owen Taylor wrote: standard: choose this if none of the above apply; in particular choose this if you are using an alternate-desktop spin of Fedora I'd add a comma right after in particular. Feedback from this wide audience appreciated. Would you know what option to pick? Yes, it's clear. I agree with Rahul that standard is not a great name for the nonstandard, non-productized upgrade, though. Generic is more descriptive anyway. 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: How to handle upgrades to Fedora 21
On Fri, Oct 03, 2014 at 06:18:11PM -0500, Michael Catanzaro wrote: I agree with Rahul that standard is not a great name for the nonstandard, non-productized upgrade, though. Generic is more descriptive anyway. But vanilla is the most delicious. -- 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: How to handle upgrades to Fedora 21
Hi, I agree with Rahul that standard is not a great name for the nonstandard, non-productized upgrade, though. Generic is more descriptive anyway. I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard: 1) fedora-release-nonstandard 2) fedora-release-custom 3) fedora-release-diy 4) fedora-release-noncompliant and i'll just throw another out there now 5) fedora-release-respin If we do want to change it, it should happen soon --Ray -- 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: How to handle upgrades to Fedora 21
On 09/24/2014 06:16 PM, Stephen Gallagher wrote:
* Upgrades from Fedora 20 remain non-productized. They pick up
fedora-release-standard and upgrade only their existing packages.
Can you please explain to me, what is the difference between non-productized
Fedora and productized Fedora?
Do I understand it correctly that non-productized Fedora have fedora-release-standard package, while productized one
have fedora-release-{cloud,workstation,server} package? Or is there some other difference?
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
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: How to handle upgrades to Fedora 21
On Thu, 2014-10-02 at 15:33 +0200, Miroslav Suchý wrote:
On 09/24/2014 06:16 PM, Stephen Gallagher wrote:
* Upgrades from Fedora 20 remain non-productized. They pick up
fedora-release-standard and upgrade only their existing packages.
Can you please explain to me, what is the difference between non-productized
Fedora and productized Fedora?
Do I understand it correctly that non-productized Fedora have
fedora-release-standard package, while productized one
have fedora-release-{cloud,workstation,server} package? Or is there some
other difference?
The presence of those packages makes other things possible (like adding
strict dependencies to the release packages to ensure a minimal platform
is available). Other things that it does is allow us to have yum
dependencies select an appropriate configuration sub-package for certain
projects that have different defaults between Products (the most obvious
example today being the firewalld package; it has a vastly different
default configuration depending on the Product).
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: How to handle upgrades to Fedora 21
On Wed, 2014-09-24 at 12:16 -0400, Stephen Gallagher wrote: There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: 1) Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. I've had a number of conversations with the yum/dnf and fedup people over the last week. The tl;dr version: option 1) is the only realistic option. So, a bit more contributing detail: First, the Products have both a minimal set and a default set of functionality that they want to have exposed if that Product is installed. What we've decided that this means is that, barring explicit influence, anyone who is installing Fedora Workstation or Fedora Server should be getting the default set of functionality and can later (or in a kickstart file) trim it back. Without changing the fedup package in Fedora, we could do upgrades to each of the Products or non-productized versions by providing on F20 a do-nothing fedora-release-[standard|cloud|server|workstation] file that in F21 has explicit requirements on any of the packages necessary to reach the minimal set of functionality. We can't force it to the default set (without allowing RPM soft dependencies, which is not currently supported or well-tested in Fedora), so upgrading through this path wouldn't guarantee the preferred result state (particularly for Workstation, which wants to have a certain set of common applications installed by default). Furthermore, it makes the upgrade process more complicated because it would require the user to manually install 'fedora-release-standard' in order to get the non-productized experience and they would not be able to upgrade *at all* without selecting one of them. Fedora officially only supports upgrades from a *fully-upgraded Fedora* to the next version, so we could work around this by adding a temporary explicit Requires: fedora-release-standard on the F20 fedora-release package, thereby forcing all upgrades to be non-productized. This is my recommended approach as it requires only a single change (the added Requires:) to fedora-release to make it work. The end-result of this upgrade is a system that is just a newer version of whatever DIY set of packages the previously-F20 system was running. It's also possible that we could rig up a selectable approach by creating a full set of empty fedora-release-* packages and arranging it so that fedora-release-standard satisfied the upgrade requirement if it wasn't specified, but this requires us to make sure that the automatic dependency-resolution for all of yum, dnf, gnome-software, yumex and apper all selects the correct default. I know for a fact that at least yum and dnf follow different resolution patterns, so while it could be possible, it would be a nasty hack relying on internal knowledge of the tools. That seems somewhat fragile to me, but it could be done if we strongly want it. The thing to note is that in all scenarios, the user *MUST* fully update their F20 system first, or the results will be undefined and could be unpleasant. We need to spell this out very clearly to our upgrading users. 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: How to handle upgrades to Fedora 21
On 09/24/2014 06:22 PM, Jaroslav Reznik wrote: - Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: * Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to. I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines). I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, - --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group. Maybe we can go with first option and say, upgrades to products are not supported, please reinstall. It's new beginning and say non-productized update support will be gone in F22 timeframe and only productized updates will be allowed. In RHEL we are using preupgrade-assistant [1] which does this work. If user write a check script then it will inform user that upgrade is not supported. The check script can also inform user that e.g. mariadb changed structure and it's required to execute a convert script or whatever. Currently now preupgrade-assistant is not available in Fedora. I discussed with Honza Horak (team lead of databases) about this issues and can be used in this case. There is only one issue. Each package maintainer should create own subpackage with check script which should be used on Fedora. And I think that this is a bit problematic. From time point of view [1] https://github.com/phracek/preupgrade-assistant In Czech we say Když se kácí strom, létají třísky - Google Translate is your friend :). Jaroslav -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQi7kYACgkQeiVVYja6o6OMSACgjZqFxjISnfEhVVSXWLs7HENf cIwAoK6e/Dp1uLvVX1feUr4gouTwhKsd =U4A7 -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 -- Best regards / S pozdravem Petr Hracek -- 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: How to handle upgrades to Fedora 21
2014-09-30 15:04 GMT+02:00 Petr Hracek phra...@redhat.com: In RHEL we are using preupgrade-assistant [1] which does this work. If user write a check script then it will inform user that upgrade is not supported. The check script can also inform user that e.g. mariadb changed structure and it's required to execute a convert script or whatever. Currently now preupgrade-assistant is not available in Fedora. I discussed with Honza Horak (team lead of databases) about this issues and can be used in this case. There is only one issue. Each package maintainer should create own subpackage with check script which should be used on Fedora. No thanks. You should suggest a more targeted approach than adding such a burden to package maintainers. And I think that this is a bit problematic. From time point of view [1] https://github.com/phracek/preupgrade-assistant In Czech we say Když se kácí strom, létají třísky - Google Translate is your friend :). Jaroslav -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQi7kYACgkQeiVVYja6o6OMSACgjZqFxjISnfEhVVSXWLs7HENf cIwAoK6e/Dp1uLvVX1feUr4gouTwhKsd =U4A7 -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 -- Best regards / S pozdravem Petr Hracek -- 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: How to handle upgrades to Fedora 21
No, definitely not. preupgrade-assistant is only the tool which informs user or admin what was change against the newest version and recommend actions for inplace upgrades. But as I mentioned. Currently now it's not available in Fedora. Preupgrade-assistant doesn't modify system at all. On 09/30/2014 03:50 PM, Rahul Sundaram wrote: Hi On Tue, Sep 30, 2014 at 9:04 AM, Petr Hracek wrote: In RHEL we are using preupgrade-assistant [1] which does this work. If user write a check script then it will inform user that upgrade is not supported. The check script can also inform user that e.g. mariadb changed structure and it's required to execute a convert script or whatever. Currently now preupgrade-assistant is not available in Fedora. I discussed with Honza Horak (team lead of databases) about this issues and can be used in this case. So preupgrade was replaced by fedup in Fedora and now you want to introduce another tool called preupgrade-assistant which is entirely different? Can't you folks get together and focus on one tool, whatever that is? Rahul -- Best regards / S pozdravem Petr Hracek -- 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: How to handle upgrades to Fedora 21
HI On Tue, Sep 30, 2014 at 9:57 AM, Petr Hracek wrote: No, definitely not. preupgrade-assistant is only the tool which informs user or admin what was change against the newest version and recommend actions for inplace upgrades. But as I mentioned. Currently now it's not available in Fedora. So why can't this functionality be part of fedup exactly? Rahul -- 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: How to handle upgrades to Fedora 21
Or better say, fedup remains as tool for upgrades. On 09/30/2014 03:57 PM, Petr Hracek wrote: No, definitely not. preupgrade-assistant is only the tool which informs user or admin what was change against the newest version and recommend actions for inplace upgrades. But as I mentioned. Currently now it's not available in Fedora. Preupgrade-assistant doesn't modify system at all. On 09/30/2014 03:50 PM, Rahul Sundaram wrote: Hi On Tue, Sep 30, 2014 at 9:04 AM, Petr Hracek wrote: In RHEL we are using preupgrade-assistant [1] which does this work. If user write a check script then it will inform user that upgrade is not supported. The check script can also inform user that e.g. mariadb changed structure and it's required to execute a convert script or whatever. Currently now preupgrade-assistant is not available in Fedora. I discussed with Honza Horak (team lead of databases) about this issues and can be used in this case. So preupgrade was replaced by fedup in Fedora and now you want to introduce another tool called preupgrade-assistant which is entirely different? Can't you folks get together and focus on one tool, whatever that is? Rahul -- Best regards / S pozdravem Petr Hracek -- Best regards / S pozdravem Petr Hracek -- 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: How to handle upgrades to Fedora 21
Hi On Tue, Sep 30, 2014 at 9:04 AM, Petr Hracek wrote: In RHEL we are using preupgrade-assistant [1] which does this work. If user write a check script then it will inform user that upgrade is not supported. The check script can also inform user that e.g. mariadb changed structure and it's required to execute a convert script or whatever. Currently now preupgrade-assistant is not available in Fedora. I discussed with Honza Horak (team lead of databases) about this issues and can be used in this case. So preupgrade was replaced by fedup in Fedora and now you want to introduce another tool called preupgrade-assistant which is entirely different? Can't you folks get together and focus on one tool, whatever that is? Rahul -- 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: How to handle upgrades to Fedora 21
Preupgrade assistant performs assessment of the system from the upgradeability point of view. It is based on OpenSCAP engine. It reports potential risks for in-place upgrading system. fedup can call our API. For sure. That's all. On 09/30/2014 03:59 PM, Rahul Sundaram wrote: HI On Tue, Sep 30, 2014 at 9:57 AM, Petr Hracek wrote: No, definitely not. preupgrade-assistant is only the tool which informs user or admin what was change against the newest version and recommend actions for inplace upgrades. But as I mentioned. Currently now it's not available in Fedora. So why can't this functionality be part of fedup exactly? Rahul -- Best regards / S pozdravem Petr Hracek -- 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: How to handle upgrades to Fedora 21
Hi On Tue, Sep 30, 2014 at 10:11 AM, Petr Hracek wrote: Preupgrade assistant performs assessment of the system from the upgradeability point of view. It is based on OpenSCAP engine. It reports potential risks for in-place upgrading system. fedup can call our API. For sure. Was there any discussion with the fedup maintainer to do this? Rahul -- 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: How to handle upgrades to Fedora 21
On 2014-09-24, 16:22 GMT, Jaroslav Reznik wrote: In Czech we say Když se kácí strom, létají třísky I have to admit I have hard time with this proverb. Whenever I hear somebody to use it is usually to cover for his mistakes or worse (it was a favorite proverb of https://en.wikipedia.org/wiki/Klement_Gottwald) Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
How to handle upgrades to Fedora 21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: * Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to. I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines). I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, - --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQi7kYACgkQeiVVYja6o6OMSACgjZqFxjISnfEhVVSXWLs7HENf cIwAoK6e/Dp1uLvVX1feUr4gouTwhKsd =U4A7 -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: How to handle upgrades to Fedora 21
- Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: * Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to. I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines). I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, - --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group. Maybe we can go with first option and say, upgrades to products are not supported, please reinstall. It's new beginning and say non-productized update support will be gone in F22 timeframe and only productized updates will be allowed. In Czech we say Když se kácí strom, létají třísky - Google Translate is your friend :). Jaroslav -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQi7kYACgkQeiVVYja6o6OMSACgjZqFxjISnfEhVVSXWLs7HENf cIwAoK6e/Dp1uLvVX1feUr4gouTwhKsd =U4A7 -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 -- 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: How to handle upgrades to Fedora 21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/24/2014 12:22 PM, Jaroslav Reznik wrote: - Original Message - There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: * Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to. I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines). I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group. Maybe we can go with first option and say, upgrades to products are not supported, please reinstall. It's new beginning and say non-productized update support will be gone in F22 timeframe and only productized updates will be allowed. Well, that cannot be the case, since it would leave the users of Spins completely out in the cold. That's something we've asserted numerous times now that we won't do. In Czech we say Když se kácí strom, létají třísky - Google Translate is your friend :). Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQi8BAACgkQeiVVYja6o6PwsACgjaekfg/iUEHIjzCDtX+HlSku 3q4AmgJySKNxCkF3a2o8N7VINCd3I9dx =ODjr -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: How to handle upgrades to Fedora 21
On Wed, Sep 24, 2014 at 12:16:06PM -0400, Stephen Gallagher wrote: I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, - --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps I'm in favor of either of these. I'd suggest aiming for the last but falling back to the first if it's not working in the beta? -- 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: How to handle upgrades to Fedora 21
Am 24.09.2014 um 18:16 schrieb Stephen Gallagher: There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: * Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to. I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines). I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group while i talk here only about YUM instead of fedup it may also be a matter of dependencies at the end: i would strongly prefer non-productized because i have around 30 machines upgraded now from F9 to F20 with YUM and they are all strongly customized all sort of servers, workstations and all of them are stripped-down setups with no unused package installed pull a desktop on a nameserver with 291 packages - no thanks :-) for me the products are a nice thing for a lot of users to get sane combinations targeting the needs, on the other hand many server admins likely want to continue with minimal installs and add additional packages as needed (we do that with meta-packages only defining dependencies) because it don't happen often enough to install a phyiscal machine from scratch compared to clone the golden master virtual machine signature.asc Description: OpenPGP digital 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: How to handle upgrades to Fedora 21
Am 24.09.2014 um 18:22 schrieb Jaroslav Reznik: Maybe we can go with first option and say, upgrades to products are not supported, please reinstall. It's new beginning and say non-productized update support will be gone in F22 timeframe and only productized updates will be allowed don't do that - it would hit machines installed 2008 with F9 which even survived migration to systemd, UsrMove and grub2 for no real good reasons and *please* don't break yum distro-sync upgrades signature.asc Description: OpenPGP digital 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: How to handle upgrades to Fedora 21
- Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/24/2014 12:22 PM, Jaroslav Reznik wrote: - Original Message - There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: * Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to. I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines). I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group. Maybe we can go with first option and say, upgrades to products are not supported, please reinstall. It's new beginning and say non-productized update support will be gone in F22 timeframe and only productized updates will be allowed. Well, that cannot be the case, since it would leave the users of Spins completely out in the cold. That's something we've asserted numerous times now that we won't do. Ah, you're right. On the other hand I think all spins are somehow desktop related (at least now), so moving spins to use workstation as the base is probably desirable. Actually, it was one of the ultimate plans for Workstation. Jaroslav In Czech we say Když se kácí strom, létají třísky - Google Translate is your friend :). Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQi8BAACgkQeiVVYja6o6PwsACgjaekfg/iUEHIjzCDtX+HlSku 3q4AmgJySKNxCkF3a2o8N7VINCd3I9dx =ODjr -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 -- 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: How to handle upgrades to Fedora 21
Hi On Wed, Sep 24, 2014 at 12:35 PM, Jaroslav Reznik wrote: Ah, you're right. On the other hand I think all spins are somehow desktop related (at least now), so moving spins to use workstation as the base is probably desirable No. It is not. Workstation is GNOME based. Most spins are for alternative desktop environments Rahul -- 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: How to handle upgrades to Fedora 21
- Original Message - Hi On Wed, Sep 24, 2014 at 12:35 PM, Jaroslav Reznik wrote: Ah, you're right. On the other hand I think all spins are somehow desktop related (at least now), so moving spins to use workstation as the base is probably desirable No. It is not. Workstation is GNOME based. Most spins are for alternative desktop environments Well, initial plan was other desktop environments are going to use workstation as base. It definitely makes sense, we want to have a base for all desktops (aka having same underlaying technology aka GStreamer, UDisks) and it would simplify upgrades a lot. Also I still hope we will overcome all GNOME, KDE, BLABLA based thing and will ship Workstation product that serves it's purpose, showing the best open source software. First step with inclusion of Qt and KDE libs is being done. But it's another discussion. Jaroslav Rahul -- 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: How to handle upgrades to Fedora 21
On 09/24/2014 06:16 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: * Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to. I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines). Fourth option might be to make all installations that have gnome-shell installed become Workstation, and leave others non-productized. -- 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: How to handle upgrades to Fedora 21
On 09/24/2014 11:28 AM, Kalev Lember wrote: Fourth option might be to make all installations that have gnome-shell installed become Workstation, and leave others non-productized. This is hardly a guarantee. I have several servers that get a default Fedora install and I don't bother removing X and friends because the reduced drive usage is meaningless. -- 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: How to handle upgrades to Fedora 21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 24 Sep 2014 18:29:11 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 24.09.2014 um 18:16 schrieb Stephen Gallagher: There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: * Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to. I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines). I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group while i talk here only about YUM instead of fedup it may also be a matter of dependencies at the end: i would strongly prefer non-productized because i have around 30 machines upgraded now from F9 to F20 with YUM and they are all strongly customized all sort of servers, workstations and all of them are stripped-down setups with no unused package installed pull a desktop on a nameserver with 291 packages - no thanks :-) for me the products are a nice thing for a lot of users to get sane combinations targeting the needs, on the other hand many server admins likely want to continue with minimal installs and add additional packages as needed (we do that with meta-packages only defining dependencies) because it don't happen often enough to install a phyiscal machine from scratch compared to clone the golden master virtual machine I have updated a few machines by running yum --releasever=21 install fedora-release then yum distro-sync and not had any issues. As I understand this thread it is soley about what to do in the case of using fedup only. in which case we need to setup some things in mirrormanager and do some testing and see what happens. note that we may not be able to use the fedora-install-21 prefix as the install trees all have a prefix already assigned Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUIvuKAAoJEH7ltONmPFDRSaYP/12my8HNWvUc7x5hZrJYU9z8 DTR1QQpT8KF82/AbqGibwX3+4AHIqt5koBK1SzylrRdc8l6qkte4VPYLM84kdXTi MyqJxe0kKQMmGcSCeUwLsL6yxQwex6I7Ve0dq1FxqeMVXb0mZplc/Ac6gmlGIhnq +Mj75qtJipDNncbY3BrVTCX/09qE1nbaBMPXRTSqkRmAc805eyw4I6qjvcGNMePB 1Vc56S6fxTvXti2uBX/TwzRTz0gbdb9MQg/cHr5bzw8peqoQZSbvTCRt8NuDaBaV L4nXRrFbLHKqFJSZ9XsHedHsZtQwARVSomHqJPgXMvYUYyq4sGnd1wvOvXRtMukN mgfzktAe4xiuJDY0uMuhCXD6bGMt2bhEjqsCX/AWMtSgi5QIFhVYg2mptuegVJMZ MGoXIUmmLEpkX1HXlWfDp7Hs5lXLkdC2pH+l90GAwPD1FwSTsUZmboNZIFwE3ijg EG17xwrAv1JV7J3YbjByt5f5EeEfZSNa20Gfc6Z8s0PfeEG4ttiraI9HqxG3Vi9W UXb8WuofaiaqdRWEs4EIevWiCFo4GPncfawCi0XV+s6T8s7T0V8D4wmnNL8/VI7/ 0CwRE8FiN1ZvRL9d2n7GvSCVyF3jqKMCPmT3yzZLdrgzT991sVkvrkBzvhtIfDXX ynikTgo/x8nhAvs20FiX =NMZy -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: How to handle upgrades to Fedora 21
Am 24.09.2014 um 19:12 schrieb Dennis Gilmore: I have updated a few machines by running yum --releasever=21 install fedora-release then yum distro-sync and not had any issues. As I understand this thread it is soley about what to do in the case of using fedup only. in which case we need to setup some things in mirrormanager and do some testing and see what happens. note that we may not be able to use the fedora-install-21 prefix as the install trees all have a prefix already assigned thank you for clarify signature.asc Description: OpenPGP digital 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: How to handle upgrades to Fedora 21
On Wed, Sep 24, 2014 at 6:22 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: * Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to. I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines). I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, - --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group. Maybe we can go with first option and say, upgrades to products are not supported, please reinstall. It's new beginning and say non-productized update support will be gone in F22 timeframe and only productized updates will be allowed. That's a lame excuse really. Please reinstall is more or less telling users go away. So that's not really an option (there aren't even any technical reasons for it). -- 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: How to handle upgrades to Fedora 21
On 24 September 2014 10:16, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products. Several suggestions have been made that warrant discussion: * Upgrades from Fedora 20 remain non-productized. They pick up fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to. * No upgrades from 20 to 21 are supported. This makes 21 a relative 1 and we are working from then on about upgrades working. [I am not for this idea but realized it was an option not presented and someone might think it is a good one to be on the table.] I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines). I agree with this. I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, - --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQi7kYACgkQeiVVYja6o6OMSACgjZqFxjISnfEhVVSXWLs7HENf cIwAoK6e/Dp1uLvVX1feUr4gouTwhKsd =U4A7 -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 -- 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: How to handle upgrades to Fedora 21
On Wed, 24 Sep 2014 12:27:04 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Wed, Sep 24, 2014 at 12:16:06PM -0400, Stephen Gallagher wrote: I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, - --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps I'm in favor of either of these. I'd suggest aiming for the last but falling back to the first if it's not working in the beta? +1 Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: How to handle upgrades to Fedora 21
On Wed, 24 Sep 2014 17:14:40 -0400 Simo Sorce s...@redhat.com wrote: On Wed, 24 Sep 2014 12:27:04 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Wed, Sep 24, 2014 at 12:16:06PM -0400, Stephen Gallagher wrote: I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, - --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps I'm in favor of either of these. I'd suggest aiming for the last but falling back to the first if it's not working in the beta? +1 Sounds reasonable, but might be best to talk to the fedup maintainer and see how on-board with those changes he is. ;) 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
