On Fri, 2014-10-03 at 13:50 -0400, Owen Taylor wrote: > The discussion about F20 to F21 upgrades has been largely focused on the > technolaogy - what will happen if we make package X depend on package Y > and obsolete package Z. I understand the motivation behind wanting > upgrades to be encoded in the package set and to keep special casing to > a minimum. But I think we can't just shrug and consider that the end - > we need to know what we are trying to achieve to figure out when we need > to special case and do ugly things to get there. > > Before going too far into the practicalities of what we can achieve for > Fedora 21, I decided try to write down what we'd want for F21 => F22 and > beyond. I mean this to be Workstation specific - not apply to other > products or non-productized installations of Fedora. > > * The end result of an upgrade to F<n> must have all the packages that > would have been installed for a fresh install of F<n> > Yes, with the obvious subtext that this should be additive-only. I.e. if Workstation 22 decides that Geary is the default email client, it should NOT remove Evolution or Thunderbird or Claws, etc. (This was probably understood already, but it's useful to have it be explicit.) > * In general, packages that were originally installed by default on the > system, but no longer installed by default in F<n> should be removed. > This may not always be practical, but after the upgrade: No, absolutely not. I disagree vehemently. See above. Upgrades must *never* remove a user's chosen applications. > - There must be no duplication of applications in system roles. For > example, there must not be two character map applications System-level tools makes some sense. > - There should be no left over system services started at boot I REALLY don't think this is acceptable. You're making decisions about what services the user wants to run. It's *arguable* about GNOME-internal services, but if for example we stopped shipping CUPS on the default install, it's REALLY not acceptable to disable and remove it from an installed system. > If a default application is removed without any replacement in the new > default set (e.g. we stop installing an office suite), leaving the old > application is acceptable. I don't like that "don't take things away from the user" is kind of an afterthought here. I also REALLY don't like the idea of arbitrarily replacing important software like an office suite. If we suddenly decide that Koffice is better in the default set than LibreOffice, we shouldn't be forcing that on our users. I have no problem if they are coexisting after upgrade, but one should not replace the other unless they are fully backwards-compatible with what is being replaced (such as how LibreOffice replaced OpenOffice.org) > > * Normal user configuration of the pre-upgraded system via > (non-tweak-tool) desktop configuration must not leave the system in a > broken state after the upgrade. > Meaning knobs in the gnome-settings panel, I assume. I note that you make no claims at all about extensions, which I understand the technical reasons for, but it's still not ideal for a user. Perhaps we can have the upgrade tool try to detect extensions and warn that they may not work after upgrading? (I realize this is difficult to do in the general case, but maybe just for extensions running in the active session?) > * After the upgrade, the user should see the new defaults for things > like backgrounds unless they have explicitly configured non-default > settings. Agreed. > > * We test the following upgrades: > > fresh install F<n-1> => f<n> > fresh install F<n-2> => f<n> I don't think this has ever been a policy, and upgrading from F19->F21 productized adds more trouble to the process for dubious gains. > serial upgrade fresh install F<n0> => F<n0+1> => ... f<n> (n0 to be > determined - f20 or f21 most likely) I don't know what exactly that means. Could you rephrase it?
Attachment:
signature.asc
Description: This is a digitally signed message part
-- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
