----- Original Message ----- > From: "Reindl Harald" <h.reindl@xxxxxxxxxxxxx> > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Thursday, January 26, 2012 7:15:51 AM > Subject: Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17? > > > > Am 26.01.2012 05:02, schrieb Rahul Sundaram: > > On 01/26/2012 09:23 AM, Reindl Harald wrote: > > > >> i see really nothing wrong in demanding not break things randomly > >> without > >> VERY good reasons and in this context it does relly not matter > >> if opensource /paid / whatever > > > > Nobody breaks things randomly. Sometimes changes have > > unintentional > > side effects. > > since this happens much too often it should be considered > what is wrong in the way making big changes and if it is > really needed / useful to make them so big > > this transition could be done with less drastic effects by > start change the locations of updated packages, targeting > empty top-level dirs in the next release and file bugreports > for every single file existing after that > > finally you have the directories empty and they can be removed > > the first step could be even install the new binaries to > /usr/bin/ and create symlinks in /bin/ which will be > removed in the next release > > if i have learned something in the last 10 years in this > business is that updates / transitions should be done > careful and slowly to prevent damage > > as example we develop our own cms-system serving currently > 170 domains and they all get updated FULLY automated > permanently which is only possible because small steps > and making for every update which needs changes in the > database a 100% working transition which is tested for > a day and after that i can update 100, 1000, 10000 > setups with one step - and yes it needs good backward > compatibility to make sure that customized modules > are not broken and you have all the time is needed > to port them to new APIs and drop the old ones a year > later after all transitions are done > > this does not happen this way because it is payed > this happens this way because it saves time and energy > on my side (things get never broken), improve security > drastical because you can deploy fixes at any time > and can make os/php/mysql-upgrades at every time > with prepared updates Let me start that I'll miss yum upgrade badly! Looking at the feature page though is making me think that this is really incremental approach. Move everything in usr this release and benefit from it in consequent releases(F-18) (snapshoting and etc.). If a more conservative approach is taken we will have e.g. everything moved to /usr in F-17, symlinks from bin removed in F-18, bin|sbin|lib made symlinks in F-19 and etc. If we move that slow by the time we have a feature it will so badly outdated that it might be irrelevant or already a commodity so noone is considering Fedora as a contender. Note that I speak overall not just in the Linux/Unix world. Alex > > >>>> "User Experience: less toplevel directories " > >>>> > >>>> "On new installation: create symlinks /bin -> usr/bin, /sbin -> > >>>> usr/sbin, /lib -> usr/lib, /lib64 -> usr/lib64" > > what the hell makes this whole change useful if you have > finally the same toplevel-tree and only some pieces > replaced by symlinks? > > this makes sense for updated installations but not for new ones > > > You could send patches or make a convincing argument as > > to why the problem needs to be fixed. > > i made a hughe argument with updating a lot of live servers > via yum and hwat i do not understand since many years is > that yum-upgrades are not offical supported > > they are running most of the time much better than anaconda > ever did and should be the primary update path having DVD > only as fallback if somethign went terrible wrong > > > > > > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
