While I take issue with how Reindl is presenting his case, I'd just like to add a concurring voice to the original point: this will negatively affect a particular swath of users, of which I am one. Media-driven upgrades aren't a reasonable option for my (admittedly small) collection of machines, all of which are managed remotely and with a number of other constraints that I won't bore the list with (as they're mainly self-imposed). I suspect we're not the only ones for whom this will be a difficult release. Not impossible by any stretch, but it will be, to be blunt, a rather large pain in the ass for a particular class of user. ---- It's interesting to me to consider this change in the context of the rolling release thread. (This is me trying to be constructive and get people thinking, rather than the more argumentative approach I've seen some folks taking so far. Let's see if it works. :)) Without revealing my own preference about rolling releases: how would a change like this, whose deployment is *significantly* eased with install-time magic, be deployed in a rolling-release world? (ie. add the constraint that, once a machine is installed, ongoing updates are performed without media; not that they are performed with "yum upgrade", just that they are performed without physical media, and with an eye toward minimal "offline time".) How would the approach change? Could you (with effort) handle the relocation of /bin and friends at runtime, or is this just one of those times where you naturally need to boot to an upgrade process to implement? If we decide a boot to perform our magic is required (I concede that the runtime case has a few chicken-and-egg problems to solve, and backporting the RPM changes would probably be a requirement), could the necessary initramfs and upgrade tooling be provided/generated as part of a helper package for "yum upgraders," and documented on the wiki (require a single reboot to do the minimal heavy lifting of the relocation, then back to a running system for the actual upgrade)? Or perhaps a more elegant solution that you could envision? (If you hadn't guessed, I agree with the rationale for UsrMove; I think it's a win. It just seems that more thought could be put into how deployment has been implemented to make a few use cases more reasonable. systemd-as-default was made to wait a release to make sure the details were right; punting for a single release cycle isn't the end of the world, for any feature.) Anyway, food for thought. (And a potential real-world case for the rolling-release proponents to consider.) On Wed, Jan 25, 2012 at 11:37 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: > Am 26.01.2012 08:06, schrieb Aleksandar Kurtakov: >> ----- 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 >>> >> Let me start that I'll miss yum upgrade badly! > > the package manager and clean update transitions are so much > imprtant that breaking them is no option as long anybody > works on changes wants to say he does things right > >> 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. > > in other words: > > "better making things fast to be first and early instead make them right" > > yes, this is exactly what happens the last years and makes me so > angry because it results in NEVER have software working right > because you have always some thing broken with the legitimation > "but after that always will better" and sadly if this may be true > for one piece the next goes down > > this way you will never ever in this life get things working fine > at all and this should be the target and not making changes and > development for its own > > the only result you have is the bad taste in the mouth > "the question is not if anything is broken, the question is how > many things are broken at the same time and hopefully most of > them does not hurt too bad" > > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- Ed Marshall <esm@xxxxxxxxx> Felix qui potuit rerum cognoscere causas. http://esm.logic.net/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
