Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Lennart Poettering wrote: > You know, not even its former editor seems to to believe that (or that > it was a problem), judging by the message this sarcastic posting of his > sends: > > http://rusty.ozlabs.org/?p=236 > > ;-) Hey, my arguments are not the 2 "anti" arguments he quotes. ;-) I have nothing against you personally. I have something against pointless changes to the standard file system we've been using for decades (and which is still working fine), causing pointless trouble when upgrading. As for "There are precedents in Solaris and Fedora.", the latter is what this thread is aiming at preventing. :-p Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
2012/1/28 Ralf Corsepius : > > Why stop with Solaris compatibility and not mimick Windows? > No /usr, no /bin => /redhat. Seems to be the spirit behind all this. > > Ralf > The rhetoric spoils the argument. Various people inside of Red Hat are either for this, against this, wanting to see where the train wreck will end, thinking this is the greatest innovation since Unix, etc. All the rhetoric does is cause people (inside and outside of Red Hat) to rally more around that idea no matter how silly than allow the idea to be looked at, valued for its merits and then discarded or kept. I would like to think that after 8 years of this same argument, and its ineffectiveness it would time to do something else. -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Sat, 2012-01-28 at 11:27 +, phantomjinx wrote: > Morning people, > > Having just caught onto this thread about half way through and now read > the various pages concerning the topic, I am still in the dark about > going forward. > > I have 3 machines running F15 that I am upgrading to F16 shortly. I have > been using yum to upgrade 2 of them since Fedora Core 1 so that is my > usual upgrade path. All of them have a separate /usr partition and it is > extra hassle for me to unite the partitions. > > I understand that things could gracefully break once the /usr merge has > occurred. Therefore, is there a resource to explain how to 'pre-mount > /usr into the initramfs' to avoid the breakages please? Is this > possible? Would uniting the partitions be the only possibility? > > This is intended as pragmatic questions since I am at this moment quite > neutral/ignorant on the finer points of this discussion. As far as F16 goes, you have nothing to worry about; the change is not happening in F16. It's planned for F17. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Sat, 28.01.12 11:29, Ralf Corsepius (rc040...@freenet.de) wrote: > On 01/28/2012 10:47 AM, Miloslav Trmač wrote: > > > >[1] Improved compatibility with Solaris - Seriously? We didn't need > >that level of compatibility back when Linux was a small niche, why > >would we care now? > > >I feel mildly insulted by that argument. > Why stop with Solaris compatibility and not mimick Windows? > No /usr, no /bin => /redhat. Seems to be the spirit behind all this. Actually we originally wanted to rename "/usr" to "C:\PROGA~1\" but we feared FESCO might not agree to that, on grounds that backslashes might be too hard to type on the shell prompt! But we'll propose that for F18, OK? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Fri, 27.01.12 22:40, Kevin Kofler (kevin.kof...@chello.at) wrote: > Toshio Kuratomi wrote: > > people targetting FHS compliant systems (unless the FHS changes) > > That's the biggest flaw of this "feature": It violates the FHS! You know, not even its former editor seems to to believe that (or that it was a problem), judging by the message this sarcastic posting of his sends: http://rusty.ozlabs.org/?p=236 ;-) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Morning people, Having just caught onto this thread about half way through and now read the various pages concerning the topic, I am still in the dark about going forward. I have 3 machines running F15 that I am upgrading to F16 shortly. I have been using yum to upgrade 2 of them since Fedora Core 1 so that is my usual upgrade path. All of them have a separate /usr partition and it is extra hassle for me to unite the partitions. I understand that things could gracefully break once the /usr merge has occurred. Therefore, is there a resource to explain how to 'pre-mount /usr into the initramfs' to avoid the breakages please? Is this possible? Would uniting the partitions be the only possibility? This is intended as pragmatic questions since I am at this moment quite neutral/ignorant on the finer points of this discussion. Thanks phantomjinx -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 01/28/2012 10:47 AM, Miloslav Trmač wrote: [1] Improved compatibility with Solaris - Seriously? We didn't need that level of compatibility back when Linux was a small niche, why would we care now? I feel mildly insulted by that argument. Why stop with Solaris compatibility and not mimick Windows? No /usr, no /bin => /redhat. Seems to be the spirit behind all this. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Fri, Jan 27, 2012 at 7:43 PM, Jef Spaleta wrote: > If you haven't read the new summary write-up on the benefits of the > /user feature that I think you would benefit from reading it. > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge > > If you have read it, then I fear you either don't fully understand or > do not value the long term benefits associated with the filesystem > snapshotting nor the utility of having read-only shared vendor > supplied /usr across many guest instances. Apart from fixing things that are not a problem[1], the stateless/snapshotting benefits are, AFAIK, just vaporware promises. I can't see they can work as stated because /etc and /var are quite strongly bound to the details of contents of the newly proposed /usr - and these objections were raised back when FESCo first discussed this feature. Actually getting a stateless system would require first defining what is "state" and what is "OS" (and that question will have several different answers, for good reasons!), and then doing the actual work of separating the two. We already have a readonly-root facility in initscripts, and I think that one is doing it right - giving the people that want to use these (non-default, comparatively rarely-used and site-specific) features the power to create a stateless system without burdening the most common users with it. Mirek [1] Improved compatibility with Solaris - Seriously? We didn't need that level of compatibility back when Linux was a small niche, why would we care now? I feel mildly insulted by that argument. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Adam Williamson wrote: > The reason yum upgrades are not supported is specifically to leave > open the possibility of doing significant changes that are not > compatible with yum upgrades, if the significant change has a large > enough benefit to be worth the pain of breaking the yum upgrade path. > > Ergo you can't simply state that 'anything that breaks yum upgrade is > unacceptable'. Or else we'd support yum upgrades. Well, IMHO it *should* be supported. It's by far the most reliable upgrade method we have. Upgrading with the DVD is just unsupportable due to upgrade path issues (which no amount of QA can prevent because updates to Fn-1 can go out AFTER the Fn release, so you can't block Fn for them; thus, only Fn updates, not Fn GA, will have a package with a higher EVR than Fn-1 updates; for example, unless you upgraded practically on release day, upgrading from a fully- updated F10 to F11 using the DVD left you with a broken yum!), and I think it's a big mistake to try to support it in its current state (including updates from the repository during DVD upgrades would fix that, but that would also require other changes to Anaconda to work well, such as support for more general networking setups and package signature checks), and an even bigger mistake to advertise that as the "recommended" method to upgrade. Preupgrade does not work on all setups (the /boot partition size being the main limitation) and also has other bugs plain yum does not have (code which is exercised twice a year will just not get the same amount of testing as code which is used several times a week for routine system updates). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 01/27/2012 07:43 PM, Jef Spaleta wrote: On Fri, Jan 27, 2012 at 8:43 AM, Reindl Harald wrote: if you finally want have /bin as symlink forever this whole change is only wasted time and makes no sense at all If you haven't read the new summary write-up on the benefits of the /user feature that I think you would benefit from reading it. http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge Well, ... politliness prohibits to further comment on this. Only so far: Fedora is the first Linux to implement this. I am not aware about any other having done so. Other major Linux distros currently are discussing this topic (sometimes controversially and heated), but haven't decided yet. We will see, whether they'll adopt it, or whether this "feature" will remain a "crazy RH idea" and/or be considered a "bad joke". We will see, whether users and developers will welcome it, or whether they will regard this "feature" to be yet another demonstration of Fedora users being the RH "guinea pigs". If you have read it, then I fear you either don't fully understand or do not value the long term benefits associated with the filesystem snapshotting nor the utility of having read-only shared vendor supplied /usr across many guest instances. Read-only /usr would have always been possible, if there would have been willingness to implement it and if people had cared about it. If those stated benefits are achievable in practise, I think carrying around a few symlinks in / till the heat death of the universe is a Agreed. This estimate is quite realistic, but I would not bet, Fedora will have enough user and contributors to survive the next couple of years to experience the heat death of universe. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 01/27/2012 06:33 PM, Bill Nottingham wrote: Ralf Corsepius (rc040...@freenet.de) said: On 01/27/2012 06:05 PM, Bill Nottingham wrote: Toshio Kuratomi (a.bad...@gmail.com) said: Actually... we will "always" need the compat symlinks (for a finite but definitely long value of "always"). Third party scripts, scripts that have been in use on local systems, written by people who have long since passed on (to new jobs), people targetting FHS compliant systems (unless the FHS changes), etc will all depend on those symlinks being present. Even third party software that users want to compile and run may try to install into /bin, /sbin, and /lib so we may have that problem even there. And things like /bin/sh are compiled into glibc... And hard coded into 1000s of scripts and packages. I seriously think, Fedora has many urgent problems to address than the churn this "Feature" causes. ? There's no churn required due to packages having /bin/sh in them. Sure there is - It's really sad you don't see it. This feature is drain of energy and time of the already scarce resources Fedora has and contribute to pushing Fedora more into the niche it already is in. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 09:24 +0100, Kevin Kofler wrote: > Reindl Harald wrote: > > i made several HUNDRET of dist-upgrades with yum since FC3 and > > upgrade via DVD/Preupgrade is simply UNACEPPTABLE > > +1 > > IMHO this is a showstopper and approval for UsrMove should be withdrawn and > the "feature" reverted. The reason yum upgrades are not supported is *specifically* to leave open the possibility of doing significant changes that are not compatible with yum upgrades, if the significant change has a large enough benefit to be worth the pain of breaking the yum upgrade path. Ergo you can't simply state that 'anything that breaks yum upgrade is unacceptable'. Or else we'd support yum upgrades. You have to make a more subtle argument taking into account the balance between the benefits of the proposed feature and the drawback of making yum upgrade more difficult (it's rarely actually the case that a major feature makes a yum upgrade *entirely impossible*: it's usually more that you have to jump through some manual hoops to make it work, and that appears to be the case here). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 07:40 -0800, Toshio Kuratomi wrote: > On Thu, Jan 26, 2012 at 03:26:01PM +, Peter Robinson wrote: > > On Thu, Jan 26, 2012 at 3:22 PM, Toshio Kuratomi wrote: > > > On Thu, Jan 26, 2012 at 09:25:31AM +, Peter Robinson wrote: > > >> On Thu, Jan 26, 2012 at 1:34 AM, Toshio Kuratomi > > >> wrote: > > >> > > > >> > IIRC from the discussion in FPC meetings, there should be a way to > > >> > make yum > > >> > upgrades work but you'd first have to boot up specially and run an > > >> > initial > > >> > upgrade script: > > >> > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 > > >> > > >> How does that work on headless devices? It doesn't seem to be well > > >> tested. In fact there doesn't seem to be a way to be able to test it. > > >> > > > To test -- > > > 1) install F16. > > > 2) Run through procedure outlined on wiki (once the Feature Owners fill in > > > the blanks) > > > 3) Se if you then have a working F17 system > > > > The packages aren't in F-17 yet. See the contents of the f17-usrmove > > tag in koji. > > > Ah -- I didn't understand that you wanted a method to test it *now*. Yep, > if the work hasn't landed in rawhide, there is no way to test. That's > pretty self explanatory. Well, not really. If all the builds have landed in the tag, you can construct a repo containing all of those packages, and test using that. The intent of having a tag was to allow us to test the change without landing it directly in Rawhide, so if it turns out to be too problematic, we can just 'revert' the feature by simply never tagging it into Rawhide. Unfortunately, I took Tuesday through Thursday off this week and so wasn't around to help harald and kay with announcing the packages were available for testing, setting up instructions and so forth. Hopefully no irreversible decisions (feature delays, packages tagged into Rawhide...) have happened yet, and I can take a look at this on Monday... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Toshio Kuratomi wrote: > people targetting FHS compliant systems (unless the FHS changes) That's the biggest flaw of this "feature": It violates the FHS! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Nils Philippsen wrote: > You seem to imply doing things in %pretrans is somehow safer than > somewhere else. I don't think so -- as Panu said: "The whole %pretrans > thing is a scary hack that's best seen as a last resort to do the > minimal required tweak that just cannot be done elsewhere..." I do not consider a change which requires running a script before using our regular packaging system because our packaging system cannot handle the change a safe change to do. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 01/28/2012 12:59 AM, Steve Clark wrote: >> > So this is all for the benefit of the/some "Vendor"? ??? Read the pages https://fedoraproject.org/wiki/Features/UsrMove http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge If you have questions, please be specific. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 01/27/2012 01:43 PM, Jef Spaleta wrote: On Fri, Jan 27, 2012 at 8:43 AM, Reindl Harald wrote: if you finally want have /bin as symlink forever this whole change is only wasted time and makes no sense at all If you haven't read the new summary write-up on the benefits of the /user feature that I think you would benefit from reading it. http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge If you have read it, then I fear you either don't fully understand or do not value the long term benefits associated with the filesystem snapshotting nor the utility of having read-only shared vendor supplied /usr across many guest instances. If those stated benefits are achievable in practise, I think carrying around a few symlinks in / till the heat death of the universe is a reasonable cost to pay to achieve a stateless vendor OS contained in /usr. -jef So this is all for the benefit of the/some "Vendor"? -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Fri, Jan 27, 2012 at 8:43 AM, Reindl Harald wrote: > if you finally want have /bin as symlink forever this whole > change is only wasted time and makes no sense at all If you haven't read the new summary write-up on the benefits of the /user feature that I think you would benefit from reading it. http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge If you have read it, then I fear you either don't fully understand or do not value the long term benefits associated with the filesystem snapshotting nor the utility of having read-only shared vendor supplied /usr across many guest instances. If those stated benefits are achievable in practise, I think carrying around a few symlinks in / till the heat death of the universe is a reasonable cost to pay to achieve a stateless vendor OS contained in /usr. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 01/27/2012 07:32 PM, Genes MailLists wrote: perhaps this change is wanted/needed by the new init system No, systemd does not care. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 01/27/2012 12:09 PM, Reindl Harald wrote: > > > > why in the world is a currently useless "feature" much more forced > than the change of the init-system? > perhaps this change is wanted/needed by the new init system for some reason that may not be apparent at the moment ... resource usage aside, even if its not a 'good idea' it doesn't seem like a 'bad idea' does it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 27.01.2012 18:33, schrieb Bill Nottingham: > Ralf Corsepius (rc040...@freenet.de) said: >> On 01/27/2012 06:05 PM, Bill Nottingham wrote: >>> Toshio Kuratomi (a.bad...@gmail.com) said: Actually... we will "always" need the compat symlinks (for a finite but definitely long value of "always"). Third party scripts, scripts that have been in use on local systems, written by people who have long since passed on (to new jobs), people targetting FHS compliant systems (unless the FHS changes), etc will all depend on those symlinks being present. Even third party software that users want to compile and run may try to install into /bin, /sbin, and /lib so we may have that problem even there. >>> >>> And things like /bin/sh are compiled into glibc... >> >> And hard coded into 1000s of scripts and packages. >> >> I seriously think, Fedora has many urgent problems to address than >> the churn this "Feature" causes. > > ? There's no churn required due to packages having /bin/sh in them if you finally want get rid of /bin it is if you finally want have /bin as symlink forever this whole change is only wasted time and makes no sense at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Ralf Corsepius (rc040...@freenet.de) said: > On 01/27/2012 06:05 PM, Bill Nottingham wrote: > >Toshio Kuratomi (a.bad...@gmail.com) said: > >>Actually... we will "always" need the compat symlinks (for a finite but > >>definitely long value of "always"). Third party scripts, scripts that have > >>been in use on local systems, written by people who have long since passed > >>on (to new jobs), people targetting FHS compliant systems (unless the FHS > >>changes), etc will all depend on those symlinks being present. Even third > >>party software that users want to compile and run may try to install into > >>/bin, /sbin, and /lib so we may have that problem even there. > > > >And things like /bin/sh are compiled into glibc... > > And hard coded into 1000s of scripts and packages. > > I seriously think, Fedora has many urgent problems to address than > the churn this "Feature" causes. ? There's no churn required due to packages having /bin/sh in them. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 01/27/2012 06:05 PM, Bill Nottingham wrote: Toshio Kuratomi (a.bad...@gmail.com) said: Actually... we will "always" need the compat symlinks (for a finite but definitely long value of "always"). Third party scripts, scripts that have been in use on local systems, written by people who have long since passed on (to new jobs), people targetting FHS compliant systems (unless the FHS changes), etc will all depend on those symlinks being present. Even third party software that users want to compile and run may try to install into /bin, /sbin, and /lib so we may have that problem even there. And things like /bin/sh are compiled into glibc... And hard coded into 1000s of scripts and packages. I seriously think, Fedora has many urgent problems to address than the churn this "Feature" causes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 27.01.2012 18:05, schrieb Bill Nottingham: > Toshio Kuratomi (a.bad...@gmail.com) said: >> Actually... we will "always" need the compat symlinks (for a finite but >> definitely long value of "always"). Third party scripts, scripts that have >> been in use on local systems, written by people who have long since passed >> on (to new jobs), people targetting FHS compliant systems (unless the FHS >> changes), etc will all depend on those symlinks being present. Even third >> party software that users want to compile and run may try to install into >> /bin, /sbin, and /lib so we may have that problem even there. > > And things like /bin/sh are compiled into glibc... and in a million shell scripts out there which are not part of the distribution - this change is wasted time at all the default installation doe snot seperate / and /usr i still see no sense in doing this at all! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 27.01.2012 18:00, schrieb Toshio Kuratomi: > On Fri, Jan 27, 2012 at 02:27:59PM +0100, Nils Philippsen wrote: >> On Thu, 2012-01-26 at 23:53 +0100, Kevin Kofler wrote: >>> Toshio Kuratomi wrote: >> >>> I don't understand why we absolutely HAVE to change directories to symlinks >>> when we KNOW RPM doesn't support this, and that in directories as essential >>> as /bin etc. >> >> We could wait until you have convinced people, maintainers and users >> alike, to fix their packages and scripts all in one go over to using the >> new paths, so we get by without compat symlinks. But I don't think we >> want to wait for that. Agreed, it'd be a whole lot nicer if RPM could >> handle symlink <-> non-symlink transitions without crutches like this >> one, but right now it can't. >> > Actually... we will "always" need the compat symlinks (for a finite but > definitely long value of "always"). Third party scripts, scripts that have > been in use on local systems, written by people who have long since passed > on (to new jobs), people targetting FHS compliant systems (unless the FHS > changes), etc will all depend on those symlinks being present. Even third > party software that users want to compile and run may try to install into > /bin, /sbin, and /lib so we may have that problem even there. yes, and this is one reason why i do not understand the rush doing this "feature" now in one big step with a lot of possible pitfalls instead start it slowly with change the install locations of the packages in F17 and file bugs for every package who does still install files there and place symlinks in /bi, /sbin this is a change which can be done over more releases because it does nothing change now for the users and in the meantime FHS maybe updated and third-party packages are also adopted there is no need doing such change in any rush and completly with one release especially nobody was interested to do the systemd transition in one step which would have made much more sense and solved many many problems, bugreports and a lot of time in the first step why in the world is a currently useless "feature" much more forced than the change of the init-system? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Toshio Kuratomi (a.bad...@gmail.com) said: > Actually... we will "always" need the compat symlinks (for a finite but > definitely long value of "always"). Third party scripts, scripts that have > been in use on local systems, written by people who have long since passed > on (to new jobs), people targetting FHS compliant systems (unless the FHS > changes), etc will all depend on those symlinks being present. Even third > party software that users want to compile and run may try to install into > /bin, /sbin, and /lib so we may have that problem even there. And things like /bin/sh are compiled into glibc... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Fri, Jan 27, 2012 at 02:27:59PM +0100, Nils Philippsen wrote: > On Thu, 2012-01-26 at 23:53 +0100, Kevin Kofler wrote: > > Toshio Kuratomi wrote: > > > I don't understand why we absolutely HAVE to change directories to symlinks > > when we KNOW RPM doesn't support this, and that in directories as essential > > as /bin etc. > > We could wait until you have convinced people, maintainers and users > alike, to fix their packages and scripts all in one go over to using the > new paths, so we get by without compat symlinks. But I don't think we > want to wait for that. Agreed, it'd be a whole lot nicer if RPM could > handle symlink <-> non-symlink transitions without crutches like this > one, but right now it can't. > Actually... we will "always" need the compat symlinks (for a finite but definitely long value of "always"). Third party scripts, scripts that have been in use on local systems, written by people who have long since passed on (to new jobs), people targetting FHS compliant systems (unless the FHS changes), etc will all depend on those symlinks being present. Even third party software that users want to compile and run may try to install into /bin, /sbin, and /lib so we may have that problem even there. -Toshio pgpsN2Yx2y6jj.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 27.01.2012 14:15, schrieb Nils Philippsen: > On Thu, 2012-01-26 at 15:49 +0100, Reindl Harald wrote: >> there is no limited sense of security >> each machine has a clone for backup-reasons >> this clones are updated first >> so after that i know the exactly behavior > > In a strict sense, no, you don't. Assuming that your servers have users > that keep on using them while they're being upgraded (everything else is > pointless), their actions are a big unknown bullshit - on web and fileservers their actions are exactly known and users have NEVER shell access on a server the services are running with the old versios of the service and all libraries - you can physically remove the whole httpd while it will run for days as long it is not stopped > -- you can't know ahead of > time what they'll do during the machine is upgraded, and this may > trigger behavior in the running software which you did not test before. as said above - NO >> there is ALWAYS the internal build/repo-cache server between >> and that is why anaconda is unuseable and it would be >> a shame damage this capabilities > > First, upgrading with yum never was fully supported[1], probably to > cater for situations like this one. Second, as you described it above it > seems you're not running Fedora, but your own forked off distribution (a > "Fedora Remix"[2] if you want to give it a nice-sounding moniker). You > could even forego UsrMove in your fork -- though that'd be a lot of > work: right now in F16/x86_64, there are 261 affected packages, so you > probably don't want to do that. this is only needed because fedora packages restarting services while updateing them what is UNACEPPTABLE even if yu are not doing a dist-upgrade becuse normally you test packages, deploy them and later in the evening do the restart the second problem is that most services are not converted to systemd and my old watchdog-scripts restarting crashed servcies are no longer work on top of systemd so no i gave no fork, i only solve currently design bugs in fedora and that is why i would not be amused introduce new ones instead solve the existing like set a var in /etc/sysconfig to restart services on update or not instead a braindead hardcoded restart in each SPEC-file > Anyway, I wonder what the drama is all about (and this goes to larger > parts of the audience)... I think a lot of this is based on > misunderstandings and conjecture: You already need to do certain > preparatory steps before doing a yum upgrade (e.g. install repository > GPG keys, disable and remove SELinux policy from F-13 to F-14). This > time you have additional steps[3] in order to run a script which moves > stuff about, preparing the system in a way which can't sanely be done in > RPM/YUM (re headless: AIUI this doesn't really need physical presence in > front of the box, and regardless: a serial console or similar is a good > thing to have). Then you do the upgrade as usual. What's the big deal it takes much longer to shutdown the virtual machine, add a dvd-rom, insert a iso-image, bott from this crap and hope that the system afterwards will build as a whole dist-upgrade at all normally a dist-upgarde takes 4-6 minutes per server and 20-30 secods for the reboot - believe it or not, with a stripped down installation-base on a HP ProLiant DL 380G7 , a SAN-Storageand VMware ESXi on top this are normal values signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 23:53 +0100, Kevin Kofler wrote: > Toshio Kuratomi wrote: > > https://fedorahosted.org/fpc/ticket/118#comment:7 > > Well, IMHO if this is not safe to do in a %pretrans, it is not safe to do at > all. You seem to imply doing things in %pretrans is somehow safer than somewhere else. I don't think so -- as Panu said: "The whole %pretrans thing is a scary hack that's best seen as a last resort to do the minimal required tweak that just cannot be done elsewhere..." > I don't understand why we absolutely HAVE to change directories to symlinks > when we KNOW RPM doesn't support this, and that in directories as essential > as /bin etc. We could wait until you have convinced people, maintainers and users alike, to fix their packages and scripts all in one go over to using the new paths, so we get by without compat symlinks. But I don't think we want to wait for that. Agreed, it'd be a whole lot nicer if RPM could handle symlink <-> non-symlink transitions without crutches like this one, but right now it can't. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 14:51 +, Peter Robinson wrote: > On Thu, Jan 26, 2012 at 2:43 PM, Harald Hoyer wrote: > > Am 25.01.2012 23:48, schrieb Peter Robinson: > >> Hi All, > >> > >> So I saw a rpm update and a number of other builds today when dealing > >> with various packaging bits. Checking the update [1] and reading the > >> attached bug [2] I was a little shocked to find that "yum upgrade" > >> between releases would be explicitly broken due to this feature. > > > > Not really true. "yum upgrade" will be supported, but it needs a little help > > with a special initramfs and an additiona > > So why isn't it documented as such? It is, the feature page mentions the script, the tentative preparation steps on the yum upgrade page describe the details. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 15:49 +0100, Reindl Harald wrote: > > Am 26.01.2012 15:07, schrieb Nils Philippsen: > > On Thu, 2012-01-26 at 14:19 +0100, Reindl Harald wrote: > >> > >> Am 26.01.2012 14:08, schrieb Nils Philippsen: > >>> For the sake of completeness: > >>> > >>> On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: > after a yum upgrade you can verify that the most important > things are fine BEFORE reboot (bootloader-config, > package-cleanup --problems, ), optimize/correct things > you know are not fine after the upgrade (active services > after transition to systemd as example) and then you reboot > ONCE in a clean starting system instead a boot in the blue > >>> > >>> ... as can be done on VC2 after updating with anaconda > >> > >> while the system and services are running? > >> show me how you will do this! > > > > This not what I wrote. > > you did - you wrote "as can be done" Then, this is not what you wrote :-). I was referring to what I quoted above: "after a yum upgrade you can verify that the most important things are fine BEFORE reboot..., optimize/correct things... and then you reboot..." Nowhere in the quoted text did you mention services that keep running, which I grant is a huge difference between upgrades done in yum and anaconda. Whether keeping services running while the world changes around them is a good idea, however, I doubt it. > > I am well aware of the differences between doing an upgrade with > > anaconda and doing it with yum in a live system. I've done enough of the > > latter to at least shut down critical processes (e.g. MTA, database > > server software) before doing a yum upgrade, because stuff tends to > > hick-up if you pull the rug from underneath it (e.g. if files get moved > > around, renamed, dynamically loaded modules are replaced by newer > > versions with new API, data formats change, ...). What you described > > sounds too non-deterministic for my taste. Granted, you reduce the > > amount of planned downtime with this scheme, but you trade that in for a > > heightened risk of unplanned downtime should stuff break in the process. > > And testing only buys you a limited sense of security here. > > we build critical server packages usually on our own infrastructure > and do version changes sepearted from the dist-upgrade as also > the automatic restart on update is removed from all packages > > as example we had MySQL 5.5 on F13 > > there is no limited sense of security > each machine has a clone for backup-reasons > this clones are updated first > so after that i know the exactly behavior In a strict sense, no, you don't. Assuming that your servers have users that keep on using them while they're being upgraded (everything else is pointless), their actions are a big unknown -- you can't know ahead of time what they'll do during the machine is upgraded, and this may trigger behavior in the running software which you did not test before. > there is ALWAYS the internal build/repo-cache server between > and that is why anaconda is unuseable and it would be > a shame damage this capabilities First, upgrading with yum never was fully supported[1], probably to cater for situations like this one. Second, as you described it above it seems you're not running Fedora, but your own forked off distribution (a "Fedora Remix"[2] if you want to give it a nice-sounding moniker). You could even forego UsrMove in your fork -- though that'd be a lot of work: right now in F16/x86_64, there are 261 affected packages, so you probably don't want to do that. Anyway, I wonder what the drama is all about (and this goes to larger parts of the audience)... I think a lot of this is based on misunderstandings and conjecture: You already need to do certain preparatory steps before doing a yum upgrade (e.g. install repository GPG keys, disable and remove SELinux policy from F-13 to F-14). This time you have additional steps[3] in order to run a script which moves stuff about, preparing the system in a way which can't sanely be done in RPM/YUM (re headless: AIUI this doesn't really need physical presence in front of the box, and regardless: a serial console or similar is a good thing to have). Then you do the upgrade as usual. What's the big deal here again? Nils [1]: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Upgrading_Fedora_using_yum_directly [2]: https://fedoraproject.org/wiki/Remix [3]: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Kevin Kofler wrote: > As I've already stated multiple > times, the DVD MUST be fixed to include the updates repository for > upgrades And that means that bug 998 needs to be fixed. Installing packages from the ISO image without checking them is OK, because a security-conscious user will have verified the image already, and if the image has been tampered with then it's already too late by the time Anaconda runs. Packages that Anaconda downloads are a different matter. Those haven't been verified by the user so they must be verified by Anaconda. As long as bug 998 remains unfixed I hope it will at least be possible to make a fresh install from an ISO image, using only what is included in the image. Otherwise I don't see how Fedora could be installed securely. Upgrading securely is still possible with Yum, but installation requires Anaconda as far as I know. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
I wrote: > This is not the first time a "feature" which impacts the entire > distribution in a way which can break a lot of things gets rushed in so > late. I remember the ld DSO "feature" which changed decades-old ELF > semantics, breaking the build of dozens of packages, and which got rushed > into F13 the day of the feature freeze (!), with neither the feature > owners nor FESCo wanting to postpone it to F14 even though there was no > reason at all why that change couldn't have waited for a release > (especially considering that the F14 Rawhide was about to open, which > would have been the perfect point in the schedule to land such a change). > I don't understand the rush for UsrMove either. We really need to require > such deep-impacting changes to land much earlier in the cycle (if we allow > them at all), while being more flexible for features in leaf packages. > Having a single feature freeze day for everything just doesn't work. PS: I still think both the LD DSO "feature" and this UsrMove "feature" are "features" we'd better do without. They bring no tangible benefit and lots of very tangible problems. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Toshio Kuratomi wrote: > https://fedorahosted.org/fpc/ticket/118#comment:7 Well, IMHO if this is not safe to do in a %pretrans, it is not safe to do at all. I don't understand why we absolutely HAVE to change directories to symlinks when we KNOW RPM doesn't support this, and that in directories as essential as /bin etc. The whole UsrMove "feature" is flawed and I don't understand why it didn't get thrown out immediately when proposed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Greg wrote: > as i will say again i have no problems downloading a LiveCD or a DvD. if > i have had 1 DE installed i'll download a LiveCD only rather than a DvD, Have you even READ what I wrote? Live CDs CANNOT UPGRADE, only reinstall. And no, I will definitely NOT reinstall at every release. Reinstalling trashes all the systemwide configuration, the list of installed packages etc. It's just no substitute for an upgrade. > some people havent got the bandwidth to download a DvD. i have used a > LiveCD in the past without a problem. im suspecting a lot download a > LiveCD just to install KDE or Gnome, once that's installed they then yum > the rest. For the initial installation, that's exactly what I recommend. But this is NOT AN OPTION for upgrades. > i dont see anything wrong with this Feature Fedora/Redhat want > by moving all the binaries to /usr . … which goes against the FHS and is just pointless bikeshedding. (Who cares where on the / partition the binaries end up?) > if one doesnt like it then all i can suggest is move to a different > Distro. just because it's gonna interupt people from using " yum upgrade > dist or whatever. this is the 21st century yanno. technology does improve > or get better. … which is exactly why having to burn physical media to do upgrades is entirely obsolete. > however if you wanna complain to kevin i can buy you a box of tissues. > whether this feature gets pushed in F17 or a later release its gonna be > something you cant stop. whinging about it isnt helping anyone. a quote > from Rahul i totally agree with. perhapos you should make better > approaches to Kev. 1. Can you drop the personal attacks? 2. There's still hope we can stop it. (But I'll have to take the blame for not having spoken up sooner against this nonsense "feature", I just didn't have the time to seep through the mega-thread at the time it was posted.) 3. If the decision is to go ahead with the feature anyway, it will sure not be YOU to decide it. Are you even a Fedora contributor? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Ed Marshall wrote: > 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? It would be guaranteed total and utter chaos. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Toshio Kuratomi wrote: > As you've been pointing out, this is a recipe for alpha slippage (and > since recently we've been slipping all later milestones, a slip in alpha > means a slip to the release) but I don't think the feature owners are > technically doing anything wrong under the current policy :-( This is not the first time a "feature" which impacts the entire distribution in a way which can break a lot of things gets rushed in so late. I remember the ld DSO "feature" which changed decades-old ELF semantics, breaking the build of dozens of packages, and which got rushed into F13 the day of the feature freeze (!), with neither the feature owners nor FESCo wanting to postpone it to F14 even though there was no reason at all why that change couldn't have waited for a release (especially considering that the F14 Rawhide was about to open, which would have been the perfect point in the schedule to land such a change). I don't understand the rush for UsrMove either. We really need to require such deep-impacting changes to land much earlier in the cycle (if we allow them at all), while being more flexible for features in leaf packages. Having a single feature freeze day for everything just doesn't work. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 26.01.2012 17:19, schrieb Ed Marshall: > On Thu, Jan 26, 2012 at 6:43 AM, Harald Hoyer wrote: >> Not really true. "yum upgrade" will be supported, but it needs a little help >> with a special initramfs and an additional kernel command line parameter, so >> that dracut can convert your filesystem. After this filesystem conversion, >> yum >> upgrade will work without problems. > > This satisfies my needs; a reboot for conversion is not ideal, but not > the end of the world (and understandable, in this case). > > There seems to be a great deal of resistance to the RPM changes that > are required, though, both for RHEL and Fedora (at least in their > respective BZ entries); will updated versions of rpm be generally > available in F16 and RHEL6 at the time of F17's release? > RHEL6 has all ACKs F17 is already in F15 and F16 are in updates-testing, AFAIK -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 6:43 AM, Harald Hoyer wrote: > Not really true. "yum upgrade" will be supported, but it needs a little help > with a special initramfs and an additional kernel command line parameter, so > that dracut can convert your filesystem. After this filesystem conversion, yum > upgrade will work without problems. This satisfies my needs; a reboot for conversion is not ideal, but not the end of the world (and understandable, in this case). There seems to be a great deal of resistance to the RPM changes that are required, though, both for RHEL and Fedora (at least in their respective BZ entries); will updated versions of rpm be generally available in F16 and RHEL6 at the time of F17's release? -- Ed Marshall Felix qui potuit rerum cognoscere causas. http://esm.logic.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 03:26:01PM +, Peter Robinson wrote: > On Thu, Jan 26, 2012 at 3:22 PM, Toshio Kuratomi wrote: > > On Thu, Jan 26, 2012 at 09:25:31AM +, Peter Robinson wrote: > >> On Thu, Jan 26, 2012 at 1:34 AM, Toshio Kuratomi > >> wrote: > >> > > >> > IIRC from the discussion in FPC meetings, there should be a way to make > >> > yum > >> > upgrades work but you'd first have to boot up specially and run an > >> > initial > >> > upgrade script: > >> > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 > >> > >> How does that work on headless devices? It doesn't seem to be well > >> tested. In fact there doesn't seem to be a way to be able to test it. > >> > > To test -- > > 1) install F16. > > 2) Run through procedure outlined on wiki (once the Feature Owners fill in > > the blanks) > > 3) Se if you then have a working F17 system > > The packages aren't in F-17 yet. See the contents of the f17-usrmove > tag in koji. > Ah -- I didn't understand that you wanted a method to test it *now*. Yep, if the work hasn't landed in rawhide, there is no way to test. That's pretty self explanatory. When the feature owner has to land their changes so that they're testable is laid out in the policy: * New features must be feature complete or close enough to completion by Feature Freeze so that a majority of its functionality can be tested during the Alpha and Beta releases. http://fedoraproject.org/wiki/Features/Policy/Milestones As you've been pointing out, this is a recipe for alpha slippage (and since recently we've been slipping all later milestones, a slip in alpha means a slip to the release) but I don't think the feature owners are technically doing anything wrong under the current policy :-( -Toshio pgpZAk5PCnDED.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 3:22 PM, Toshio Kuratomi wrote: > On Thu, Jan 26, 2012 at 09:25:31AM +, Peter Robinson wrote: >> On Thu, Jan 26, 2012 at 1:34 AM, Toshio Kuratomi wrote: >> > >> > IIRC from the discussion in FPC meetings, there should be a way to make yum >> > upgrades work but you'd first have to boot up specially and run an initial >> > upgrade script: >> > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 >> >> How does that work on headless devices? It doesn't seem to be well >> tested. In fact there doesn't seem to be a way to be able to test it. >> > To test -- > 1) install F16. > 2) Run through procedure outlined on wiki (once the Feature Owners fill in > the blanks) > 3) Se if you then have a working F17 system The packages aren't in F-17 yet. See the contents of the f17-usrmove tag in koji. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 09:40:33AM +0100, Kevin Kofler wrote: > I wrote: > > IMHO this is a showstopper and approval for UsrMove should be withdrawn > > and the "feature" reverted. > > PS: Oh, and I don't see why this cannot be fixed by a %pretrans scriptlet in > filesystem rather than a script we have to run by hand. That's what > %pretrans is for. (We successfully used %pretrans to convert directories to > symlinks or the opposite in a couple cases in KDE packaging in the past. > None were directories as important as the ones being touched by UsrMove > though!) And the scriptlet having been written BEFORE starting to convert > packages should have been a requirement for approving this feature. > https://fedorahosted.org/fpc/ticket/118#comment:7 -Toshio pgpaqAOcEIpC1.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 09:25:31AM +, Peter Robinson wrote: > On Thu, Jan 26, 2012 at 1:34 AM, Toshio Kuratomi wrote: > > > > IIRC from the discussion in FPC meetings, there should be a way to make yum > > upgrades work but you'd first have to boot up specially and run an initial > > upgrade script: > > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 > > How does that work on headless devices? It doesn't seem to be well > tested. In fact there doesn't seem to be a way to be able to test it. > To test -- 1) install F16. 2) Run through procedure outlined on wiki (once the Feature Owners fill in the blanks) 3) Se if you then have a working F17 system For headless devices I do not know -- you'll need the Feature Owners to answer that one. > This should have been in rawhide months ago. This is just asking for > slippage of the schedule. > Yeah, I agree that rawhide is for breakage and things should land as early as possible... but lots of people don't agree. I'm guessing that the Feature process is going to need to change to accomodate them rather than the other way around. > IMO this is too late and there's too many widely impacting things that > haven't been widely announced. Personally I think, similar to what > happened in F-14 with systemd, this feature should be pushed back to > F-18 to give the feature developers more time to properly develop and > test things like those scripts or decent procedures in order to be > able to progress this properly rather than throwing it over the fence > a week or so before feature freeze/branch and ensuring a just about > guaranteed slip of the schedule. > > This just makes a whole mockery of the Feature process and basically > gives the idea that a number of people thing they can just do as they > please, when they please and ride rough shod over the process. > Please file a fesco meeting ticket. > > I also agree with your point that this discussion should be reflected on the > > Feature page (Since the Feature page is where marketing material is taken > > from). Could that be updated as well? > > It's also where a lot of people go to figure out the impact and how > they can test various features. There's not a single mention of "yum > upgrade" breakage or change of process. > +1 -Toshio pgp0H2BCZ3P72.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 26.01.2012 15:51, schrieb Frank Murphy: > On 26/01/12 14:43, Harald Hoyer wrote: >> >> Not really true. "yum upgrade" will be supported, but it needs a little help >> with a special initramfs and an additional kernel command line parameter, so >> that dracut can convert your filesystem. After this filesystem conversion, >> yum >> upgrade will work without problems. > > Will a howto be ready for those going from F17-Rawhide\F16+ > to F17-Branched. If /usr is ready by then. > HOWTO is in the making -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 2:43 PM, Harald Hoyer wrote: > Am 25.01.2012 23:48, schrieb Peter Robinson: >> Hi All, >> >> So I saw a rpm update and a number of other builds today when dealing >> with various packaging bits. Checking the update [1] and reading the >> attached bug [2] I was a little shocked to find that "yum upgrade" >> between releases would be explicitly broken due to this feature. > > Not really true. "yum upgrade" will be supported, but it needs a little help > with a special initramfs and an additiona So why isn't it documented as such? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 26/01/12 14:43, Harald Hoyer wrote: Not really true. "yum upgrade" will be supported, but it needs a little help with a special initramfs and an additional kernel command line parameter, so that dracut can convert your filesystem. After this filesystem conversion, yum upgrade will work without problems. Will a howto be ready for those going from F17-Rawhide\F16+ to F17-Branched. If /usr is ready by then. -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 26.01.2012 15:07, schrieb Nils Philippsen: > On Thu, 2012-01-26 at 14:19 +0100, Reindl Harald wrote: >> >> Am 26.01.2012 14:08, schrieb Nils Philippsen: >>> For the sake of completeness: >>> >>> On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: after a yum upgrade you can verify that the most important things are fine BEFORE reboot (bootloader-config, package-cleanup --problems, ), optimize/correct things you know are not fine after the upgrade (active services after transition to systemd as example) and then you reboot ONCE in a clean starting system instead a boot in the blue >>> >>> ... as can be done on VC2 after updating with anaconda >> >> while the system and services are running? >> show me how you will do this! > > This not what I wrote. you did - you wrote "as can be done" > I am well aware of the differences between doing an upgrade with > anaconda and doing it with yum in a live system. I've done enough of the > latter to at least shut down critical processes (e.g. MTA, database > server software) before doing a yum upgrade, because stuff tends to > hick-up if you pull the rug from underneath it (e.g. if files get moved > around, renamed, dynamically loaded modules are replaced by newer > versions with new API, data formats change, ...). What you described > sounds too non-deterministic for my taste. Granted, you reduce the > amount of planned downtime with this scheme, but you trade that in for a > heightened risk of unplanned downtime should stuff break in the process. > And testing only buys you a limited sense of security here. we build critical server packages usually on our own infrastructure and do version changes sepearted from the dist-upgrade as also the automatic restart on update is removed from all packages as example we had MySQL 5.5 on F13 there is no limited sense of security each machine has a clone for backup-reasons this clones are updated first so after that i know the exactly behavior and these capabilities are exactly what anaconda can NOT provide >> shutdown the VM, insert the ISO and boot anaconda takes much >> longer as the whole upgrade via yum - our machines needed >> between 4 and 6 minutes each server for the whole F14->F15 >> upgrade, so in an hour you have all machines updated with >> nearly zero downtime > > If all goes well it does as explained above > The move of pretty much every basic user space > building block from / to /usr has enough potentially disruptive > qualities that I'd rather have the patient not be the surgeon in this > round of open heart surgery if you have a identical clone of a whole machine you can play around with the upgrade as often as needed (snapshots) and can prepare the whole transition, no matter preparing configurations or rebuild packages as needed the production machines are done after this tests / prepares usually it takes 1-2 days to prepare a fedora dist-upgrade for our production servers and the real update takes 5 minutes for each machine with a 100% clear step-for-step-list >> a change which damages this capabilities has to be fixed > > For the situation we're discussing, I'll take safety over > speed any time read my explanation above the way i rollout is much more safe as any anaconda update because i can prepare every single package if it is needed and our production servers NEVER access the feodra repos directly there is ALWAYS the internal build/repo-cache server between and that is why anaconda is unuseable and it would be a shame damage this capabilities while my upgrade-szenario worked from F7 to F15 on 20 machines without any single problem and from 3 upgrades with anaconda on my workstation 2 failed to boot after that and the second failed one was my last anaconda update (the one try with preupgrade did also fail) while on the other side i made around 180 yum-dist-upgrades without troubles on production environment and around 100 on test/development-VM's also without problems signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 25.01.2012 23:48, schrieb Peter Robinson: > Hi All, > > So I saw a rpm update and a number of other builds today when dealing > with various packaging bits. Checking the update [1] and reading the > attached bug [2] I was a little shocked to find that "yum upgrade" > between releases would be explicitly broken due to this feature. Not really true. "yum upgrade" will be supported, but it needs a little help with a special initramfs and an additional kernel command line parameter, so that dracut can convert your filesystem. After this filesystem conversion, yum upgrade will work without problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 14:19 +0100, Reindl Harald wrote: > > Am 26.01.2012 14:08, schrieb Nils Philippsen: > > For the sake of completeness: > > > > On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: > >> after a yum upgrade you can verify that the most important > >> things are fine BEFORE reboot (bootloader-config, > >> package-cleanup --problems, ), optimize/correct things > >> you know are not fine after the upgrade (active services > >> after transition to systemd as example) and then you reboot > >> ONCE in a clean starting system instead a boot in the blue > > > > ... as can be done on VC2 after updating with anaconda > > while the system and services are running? > show me how you will do this! This not what I wrote. > you are missing the point that "yum distro-sync" is running > while the system is up and can be distributed after testing > AUTOMATICALLY to 10,20,30,100 machines followed by a 30 > seconds reboot I am well aware of the differences between doing an upgrade with anaconda and doing it with yum in a live system. I've done enough of the latter to at least shut down critical processes (e.g. MTA, database server software) before doing a yum upgrade, because stuff tends to hick-up if you pull the rug from underneath it (e.g. if files get moved around, renamed, dynamically loaded modules are replaced by newer versions with new API, data formats change, ...). What you described sounds too non-deterministic for my taste. Granted, you reduce the amount of planned downtime with this scheme, but you trade that in for a heightened risk of unplanned downtime should stuff break in the process. And testing only buys you a limited sense of security here. > shutdown the VM, insert the ISO and boot anaconda takes much > longer as the whole upgrade via yum - our machines needed > between 4 and 6 minutes each server for the whole F14->F15 > upgrade, so in an hour you have all machines updated with > nearly zero downtime If all goes well. The move of pretty much every basic user space building block from / to /usr has enough potentially disruptive qualities that I'd rather have the patient not be the surgeon in this round of open heart surgery. In less colorful words, anaconda is self-sufficient, it brings everything it needs with it, i.e. its libc, loader and so forth won't magically move to a different place so the installer won't suddenly break because stuff it uses is removed, or in a different place or format than expected. So if something breaks badly during the upgrade I have a working shell and a small set of essential tools that continue to work regardless, with which I can fix things. This gives me enough warm fuzzy feelings that I'll happily spend the little more planned downtime on it this time. > a change which damages this capabilities has to be fixed For the situation we're discussing, I'll take safety over speed any time. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 26.01.2012 14:08, schrieb Nils Philippsen: > For the sake of completeness: > > On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: >> after a yum upgrade you can verify that the most important >> things are fine BEFORE reboot (bootloader-config, >> package-cleanup --problems, ), optimize/correct things >> you know are not fine after the upgrade (active services >> after transition to systemd as example) and then you reboot >> ONCE in a clean starting system instead a boot in the blue > > ... as can be done on VC2 after updating with anaconda while the system and services are running? show me how you will do this! you are missing the point that "yum distro-sync" is running while the system is up and can be distributed after testing AUTOMATICALLY to 10,20,30,100 machines followed by a 30 seconds reboot shutdown the VM, insert the ISO and boot anaconda takes much longer as the whole upgrade via yum - our machines needed between 4 and 6 minutes each server for the whole F14->F15 upgrade, so in an hour you have all machines updated with nearly zero downtime a change which damages this capabilities has to be fixed signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
For the sake of completeness: On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: > after a yum upgrade you can verify that the most important > things are fine BEFORE reboot (bootloader-config, > package-cleanup --problems, ), optimize/correct things > you know are not fine after the upgrade (active services > after transition to systemd as example) and then you reboot > ONCE in a clean starting system instead a boot in the blue ... as can be done on VC2 after updating with anaconda. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 08:42:15PM +1100, Greg wrote: > On 26/01/2012 7:31 PM, Kevin Kofler wrote: > >Live CDs cannot be used to upgrade existing systems. > > > >As for the DVD, it does not include the updates repository when doing > >upgrades (you can only add additional repositories for fresh installations), > >which means the process is completely broken due to the inevitable upgrade > >path issues. (You have to run "yum update" after the DVD upgrade to fix > >these, and that's if yum isn't affected by the upgrade path issues, which it > >sometimes is, e.g. it was for Fedora 11.) As I've already stated multiple > >times, the DVD MUST be fixed to include the updates repository for upgrades > >(and yes, that means offline upgrades are not possible, they're just not > >supportable; and yes, if Anaconda still doesn't support any networking other > >than basic wired Ethernet, that needs to be fixed, too); as is, DVD upgrades > >are totally unsupportable. > > > > Kevin Kofler > > as i will say again i have no problems downloading a LiveCD or a > DvD. if i have had 1 DE installed i'll download a LiveCD only rather > than a DvD, some people havent got the bandwidth to download a DvD. And yet others do not have to download either of them, because there already is (was) a perfectly reasonable way to perform an upgrade without it. > i have used a LiveCD in the past without a problem. im suspecting a > lot download a LiveCD just to install KDE or Gnome, once that's > installed they then yum the rest. i dont see anything wrong with > this Feature Fedora/Redhat want by moving all the binaries to /usr . "Fedora" is not some abstract entity with dictatorial powers. Fedora are the people who contribute to it. And they have the right to speak up when they do not like something, whether _you_ like it or not. > if one doesnt like it then all i can suggest is move to a different > Distro. This thread is not questioning the feature itself but the way it is being done. > just because it's gonna interupt people from using " yum > upgrade dist or whatever. this is the 21st century yanno. Exactly. CDs/DVDs are thing of the past, online update is the way to go. So it is questionable why we need to return to the past... > technology > does improve or get better. however if you wanna complain to kevin i > can buy you a box of tissues. whether this feature gets pushed in > F17 or a later release its gonna be something you cant stop. Again, this is not about stopping it but doing it in the least disruptive way. Btw, if you are not able to talk in reasonably polite manner, it would be better if you did not talk at all. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 26.01.2012 12:29, schrieb Greg: > On 26/01/2012 8:58 PM, Reindl Harald wrote: >> where is the improvement or does anything get better if things >> worked for years got damaged? you definition of improvement >> must have a bug! > > first thing. i agree that the Linux Filesystem needs to be cleaned up. have i said something against this? no, i speak about the HOW! > but here's my point. lets say your downloading a upgrade and the upgrade gets > to 87% and your power goes out for some time. what are you gonna do then? reboot and start again - yes i had this case in the past "yum-complete-transaction" and "package-cleanup" is your friend a small UPS does not cost too much an prevents from such cases but to be honesty - have a power outage while dist-upgrade is like win in the lottery > you'll come to the mailing list and say my yum upgrade doesnt work. WTF - who will do this in the case of a power outage and what the hell does a upgrade with DVD if your power goes down? there is no difference to a yum upgrade - you have a undefined state so please stop with such senseless arguments! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 26/01/2012 8:58 PM, Reindl Harald wrote: where is the improvement or does anything get better if things worked for years got damaged? you definition of improvement must have a bug! first thing. i agree that the Linux Filesystem needs to be cleaned up. by doing what redhat/Fedora is progressing to do with the filesystem makes it easier. its been Noted in OsNews about it. im sure elsewhere to. Google is your friend, use it. if you dont know where the improvement is, use Google. im not google. or lookup the feature page which im sure has some kinda Documentation about it. Fedora is to Test Up-coming Technology Distro that may make its way into RHEL. take for instance Grub2. may not even see its way into RHEL7 till its stable and at 2.0 . not 1.99. if your not happy with what Fedora/Redhat are doing there's is a list of Linux Distributions you can use at your own leisure. but by Demanding Fedora/Redhat not do this is a bit silly. im sure you were or have been told many times Fedora is a Testing Release for RHEL but this " Demanding " approach of yours isnt really getting anywhere . your one of these people that hate " Change" but there's no need to start Demanding things you want yourself. just because its gonna ruin you from using yum to upgrade when all one has to do is download a DvD. i know you have said it before that a DvD upgrade could or can go wrong. but here's my point. lets say your downloading a upgrade and the upgrade gets to 87% and your power goes out for some time. what are you gonna do then? you'll come to the mailing list and say my yum upgrade doesnt work. when all you had to do was download a DvD. only time i have seen a DvD install go wrong and that's when some chooses the wrong repo's during install. but yes lets go back to the dark Ages and forget about Technology. im all for redhat/Fedora doing this if it simplifies the filesystem -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 26.01.2012 10:42, schrieb Greg: > if one doesnt like it then all i can suggest is move to a different Distro. > just because it's gonna interupt people from using " yum upgrade dist or > whatever. this is the 21st century yanno. technology does improve > or get better. where is the improvement or does anything get better if things worked for years got damaged? you definition of improvement must have a bug! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 26/01/2012 7:31 PM, Kevin Kofler wrote: Live CDs cannot be used to upgrade existing systems. As for the DVD, it does not include the updates repository when doing upgrades (you can only add additional repositories for fresh installations), which means the process is completely broken due to the inevitable upgrade path issues. (You have to run "yum update" after the DVD upgrade to fix these, and that's if yum isn't affected by the upgrade path issues, which it sometimes is, e.g. it was for Fedora 11.) As I've already stated multiple times, the DVD MUST be fixed to include the updates repository for upgrades (and yes, that means offline upgrades are not possible, they're just not supportable; and yes, if Anaconda still doesn't support any networking other than basic wired Ethernet, that needs to be fixed, too); as is, DVD upgrades are totally unsupportable. Kevin Kofler as i will say again i have no problems downloading a LiveCD or a DvD. if i have had 1 DE installed i'll download a LiveCD only rather than a DvD, some people havent got the bandwidth to download a DvD. i have used a LiveCD in the past without a problem. im suspecting a lot download a LiveCD just to install KDE or Gnome, once that's installed they then yum the rest. i dont see anything wrong with this Feature Fedora/Redhat want by moving all the binaries to /usr . if one doesnt like it then all i can suggest is move to a different Distro. just because it's gonna interupt people from using " yum upgrade dist or whatever. this is the 21st century yanno. technology does improve or get better. however if you wanna complain to kevin i can buy you a box of tissues. whether this feature gets pushed in F17 or a later release its gonna be something you cant stop. whinging about it isnt helping anyone. a quote from Rahul i totally agree with. perhapos you should make better approaches to Kev. Nobody breaks things randomly. Sometimes changes have unintentional side effects. You could send patches or make a convincing argument as to why the problem needs to be fixed. Demanding doesn't help accomplish your goals at all. It just annoys people and puts people off any valid points you might make. So think carefully about this and I would recommend that you consider better approaches. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 01/26/2012 02:34 AM, Toshio Kuratomi wrote: > On Wed, Jan 25, 2012 at 10:48:27PM +, Peter Robinson wrote: >> Hi All, >> >> So I saw a rpm update and a number of other builds today when dealing >> with various packaging bits. Checking the update [1] and reading the >> attached bug [2] I was a little shocked to find that "yum upgrade" >> between releases would be explicitly broken due to this feature. >> >> Yes, I know that it's not officially recommended as a means of >> upgrading and never been QAed it has been generally supported and >> expected to work [4] for as long as I can remember. >> >> The thing that is annoying me is that this change has not been >> explicitly mentioned in the "Feature" [3], it does no appear in the >> FAQ on the feature and I don't remember it ever being bought up in the >> discussions about the feature although I admit I probably have missed >> some of the discussion. Has this side effect of the feature been >> discussed at all? Can someone point me to a thread? >> > https://fedorahosted.org/fesco/ticket/690#comment:8 > > https://fedorahosted.org/fpc/ticket/118 > > IIRC from the discussion in FPC meetings, there should be a way to make yum > upgrades work but you'd first have to boot up specially and run an initial > upgrade script: > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 > > If the Feature Owners have progressed to the implementing stae, I would > greatly appreciate them updating that page with the actual step-by-step to > perform the upgrade (which will also allow people to test that things work). > > I also agree with your point that this discussion should be reflected on the > Feature page (Since the Feature page is where marketing material is taken > from). Could that be updated as well? > > -Toshio > > > I wonder where is mentioned the change of guidelines. I didn't find at [1]. Should we stop using /bin in our new packages now or when? I really feel that this change is not well communicated and well planned. I hope someone from FPC will give us an update on changes in packaging. [1] fedoraproject.org/wiki/PackagingGuidelines Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 8:24 AM, Kevin Kofler wrote: > Reindl Harald wrote: >> i made several HUNDRET of dist-upgrades with yum since FC3 and >> upgrade via DVD/Preupgrade is simply UNACEPPTABLE > > +1 > > IMHO this is a showstopper and approval for UsrMove should be withdrawn and > the "feature" reverted. Fortunately (and IMO the major part of the problem) the core parts of the feature haven't landed yet and hence not even widely tested. This is the reason for my mail to the list so we don't have a massive blow out just before freeze ensuring a slip. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 1:34 AM, Toshio Kuratomi wrote: > On Wed, Jan 25, 2012 at 10:48:27PM +, Peter Robinson wrote: >> Hi All, >> >> So I saw a rpm update and a number of other builds today when dealing >> with various packaging bits. Checking the update [1] and reading the >> attached bug [2] I was a little shocked to find that "yum upgrade" >> between releases would be explicitly broken due to this feature. >> >> Yes, I know that it's not officially recommended as a means of >> upgrading and never been QAed it has been generally supported and >> expected to work [4] for as long as I can remember. >> >> The thing that is annoying me is that this change has not been >> explicitly mentioned in the "Feature" [3], it does no appear in the >> FAQ on the feature and I don't remember it ever being bought up in the >> discussions about the feature although I admit I probably have missed >> some of the discussion. Has this side effect of the feature been >> discussed at all? Can someone point me to a thread? >> > https://fedorahosted.org/fesco/ticket/690#comment:8 > > https://fedorahosted.org/fpc/ticket/118 > > IIRC from the discussion in FPC meetings, there should be a way to make yum > upgrades work but you'd first have to boot up specially and run an initial > upgrade script: > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 How does that work on headless devices? It doesn't seem to be well tested. In fact there doesn't seem to be a way to be able to test it. > If the Feature Owners have progressed to the implementing stae, I would > greatly appreciate them updating that page with the actual step-by-step to > perform the upgrade (which will also allow people to test that things work). They haven't yet. They were building packages yesterday under the f17-usrmove tag but there has been no heads up to any of the lists, no documentation or links to the documentation from the feature page and we're only 12 days out from feature freeze and it still hasn't landed. This should have been in rawhide months ago. This is just asking for slippage of the schedule. IMO this is too late and there's too many widely impacting things that haven't been widely announced. Personally I think, similar to what happened in F-14 with systemd, this feature should be pushed back to F-18 to give the feature developers more time to properly develop and test things like those scripts or decent procedures in order to be able to progress this properly rather than throwing it over the fence a week or so before feature freeze/branch and ensuring a just about guaranteed slip of the schedule. This just makes a whole mockery of the Feature process and basically gives the idea that a number of people thing they can just do as they please, when they please and ride rough shod over the process. > I also agree with your point that this discussion should be reflected on the > Feature page (Since the Feature page is where marketing material is taken > from). Could that be updated as well? It's also where a lot of people go to figure out the impact and how they can test various features. There's not a single mention of "yum upgrade" breakage or change of process. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
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 wrote: > Am 26.01.2012 08:06, schrieb Aleksandar Kurtakov: >> - Original Message - >>> From: "Reindl Harald" >>> To: devel@lists.fedoraproject.org >>> 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 >&
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
I wrote: > IMHO this is a showstopper and approval for UsrMove should be withdrawn > and the "feature" reverted. PS: Oh, and I don't see why this cannot be fixed by a %pretrans scriptlet in filesystem rather than a script we have to run by hand. That's what %pretrans is for. (We successfully used %pretrans to convert directories to symlinks or the opposite in a couple cases in KDE packaging in the past. None were directories as important as the ones being touched by UsrMove though!) And the scriptlet having been written BEFORE starting to convert packages should have been a requirement for approving this feature. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Greg wrote: > i don't have any problems downloading a DvD, or a LiveCD Live CDs cannot be used to upgrade existing systems. As for the DVD, it does not include the updates repository when doing upgrades (you can only add additional repositories for fresh installations), which means the process is completely broken due to the inevitable upgrade path issues. (You have to run "yum update" after the DVD upgrade to fix these, and that's if yum isn't affected by the upgrade path issues, which it sometimes is, e.g. it was for Fedora 11.) As I've already stated multiple times, the DVD MUST be fixed to include the updates repository for upgrades (and yes, that means offline upgrades are not possible, they're just not supportable; and yes, if Anaconda still doesn't support any networking other than basic wired Ethernet, that needs to be fixed, too); as is, DVD upgrades are totally unsupportable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Reindl Harald wrote: > i made several HUNDRET of dist-upgrades with yum since FC3 and > upgrade via DVD/Preupgrade is simply UNACEPPTABLE +1 IMHO this is a showstopper and approval for UsrMove should be withdrawn and the "feature" reverted. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 26.01.2012 08:06, schrieb Aleksandar Kurtakov: > - Original Message - >> From: "Reindl Harald" >> To: devel@lists.fedoraproject.org >> Sent: Thursday, January 26, 2012 7:15:51 AM >> Subject: Re: UsrMove feature breaking "yum upgrade" upgrades fromolder >> 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" signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
- Original Message - > From: "Reindl Harald" > To: devel@lists.fedoraproject.org > 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, 1 > 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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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, 1 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 "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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 04:53:33AM +0100, Reindl Harald wrote: > > > Am 26.01.2012 04:48, schrieb Rahul Sundaram: > > On 01/26/2012 08:36 AM, Reindl Harald wrote: > >> > >> > >> Am 26.01.2012 03:57, schrieb Mathieu Bridon: > > > >>> And realize that Fedora is a community project with no guarantee > >>> whatsoever. > >> > >> and that is a valueable argument for breaking things > >> without really good reasons? > > > > The problem isn't the point your raise but the tone which is always > > combative. You sound demanding and that won't get you very far. > > Repeating yourself so much doesn't help either. > > 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 > Then you need to re-evaluate your strategy. In essence, people who are not being paid monetarily are being paid in the good feelings that they get from doing their work. If you make demands in the tones you use, you are removing some of their "pay". At best, this means that the people you rant against will start to ignore you. At worst, they'll stop contributing to free software and you'll be left with the broken pieces and no one to fix them. You may have a good and valid reason why preserving yum upgrades (without the workaround that I already posted) is more important than the benefits of moving the programs from / to /usr. But unless you learn to state your reasons in a more conciliatory manner people are just going to argue with you or ignore you. -Toshio pgpwPKwHaWYIv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
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. You could send patches or make a convincing argument as to why the problem needs to be fixed. Demanding doesn't help accomplish your goals at all. It just annoys people and puts people off any valid points you might make. So think carefully about this and I would recommend that you consider better approaches. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 26.01.2012 04:48, schrieb Rahul Sundaram: > On 01/26/2012 08:36 AM, Reindl Harald wrote: >> >> >> Am 26.01.2012 03:57, schrieb Mathieu Bridon: > >>> And realize that Fedora is a community project with no guarantee >>> whatsoever. >> >> and that is a valueable argument for breaking things >> without really good reasons? > > The problem isn't the point your raise but the tone which is always > combative. You sound demanding and that won't get you very far. > Repeating yourself so much doesn't help either. 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 01/26/2012 08:36 AM, Reindl Harald wrote: > > > Am 26.01.2012 03:57, schrieb Mathieu Bridon: >> >> And realize that Fedora is a community project with no guarantee >> whatsoever. > > and that is a valueable argument for breaking things > without really good reasons? The problem isn't the point your raise but the tone which is always combative. You sound demanding and that won't get you very far. Repeating yourself so much doesn't help either. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 26.01.2012 03:57, schrieb Mathieu Bridon: > On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: >> >> Am 26.01.2012 03:03, schrieb Greg: >>> On 26/01/2012 12:46 PM, Reindl Harald wrote: i made several HUNDRED of dist-upgrades with yum since FC3 and upgrade via DVD/Preupgrade is simply UNACEPPTABLE >>> >>> i don't have any problems downloading a DvD, or a LiveCD >> >> for one simple desktop, but realize your desktop is not the world > > And realize that Fedora is a community project with no guarantee > whatsoever. and that is a valueable argument for breaking things without really good reasons? > As for any other FOSS community project, if you want something to be > guaranteed, you'll have to do it yourself or pay someone to do it. why are there so many people with this attitude? if opensource would really mean "we are breaking thins as we like the whole time and making changes without thoughs how they are affecting users" opensource would be pretty soon pretty dead > Ranting continuously on mailing lists will not gain you any sympathy sympathy alone does not bring things forward > nor is it a productive use of your own limited time and seeing things going wrong and waste the time after they gone wrong is a better use of time? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: > > Am 26.01.2012 03:03, schrieb Greg: > > On 26/01/2012 12:46 PM, Reindl Harald wrote: > >> i made several HUNDRED of dist-upgrades with yum since FC3 and > >> upgrade via DVD/Preupgrade is simply UNACEPPTABLE > > > > i don't have any problems downloading a DvD, or a LiveCD > > for one simple desktop, but realize your desktop is not the world And realize that Fedora is a community project with no guarantee whatsoever. As for any other FOSS community project, if you want something to be guaranteed, you'll have to do it yourself or pay someone to do it. Ranting continuously on mailing lists will not gain you any sympathy, nor is it a productive use of your own limited time. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 26.01.2012 03:03, schrieb Greg:
> On 26/01/2012 12:46 PM, Reindl Harald wrote:
>> i made several HUNDRED of dist-upgrades with yum since FC3 and
>> upgrade via DVD/Preupgrade is simply UNACEPPTABLE
>
> i don't have any problems downloading a DvD, or a LiveCD
for one simple desktop, but realize your desktop is not the world
but that does not interest me in any way and even on my desktop
a dvd-upgrade is unacceptable because if something goes wrong
you have no control
after a yum upgrade you can verify that the most important
things are fine BEFORE reboot (bootloader-config,
package-cleanup --problems, ), optimize/correct things
you know are not fine after the upgrade (active services
after transition to systemd as example) and then you reboot
ONCE in a clean starting system instead a boot in the blue
a dist-upgrade with yum can be made wihtout ANY DOWNTIME after
rebuild core services like httpd so that they get not restarted
while updateing and so the only downtime is the normal reboot
i am using a build/test-environment (VM guests in production)
and after confirming that the upgrade is running smooth which
is simple when no machine has access to any other repo than
the internal build/cache-repos the upgrades are done AUTOMATICALLY
it takes 5-6 minutes per production server and a reboot per
server takes around 30 secondes
so please do not tell me downloading a dvd is a valueable
option if you are not speaking about a unimportant desktop
this way dist-upgrades working SINCE YEARS and if such things
are broken this is NO IMPROVEMENT in any way!
[root@buildserver:~]$ cat /buildserver/dist-upgrade/force-live-machines.sh
#!/bin/bash
function lounge_upgrade_log
{
MY_TIME=$(date "+%d-%m-%Y %H:%M:%S")
echo "$MY_TIME $1" >> /buildserver/dist-upgrade/log-all-live.txt
echo "$MY_TIME $1"
}
lounge_upgrade_log "start server1"
ssh root@server1 "yum --releasever=15 -y --disableplugin=presto,fastestmirror
distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server1.txt
lounge_upgrade_log "server1 finished"
lounge_upgrade_log "start server2"
ssh root@server2 "yum --releasever=15 -y --disableplugin=presto,fastestmirror
distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server2.txt
lounge_upgrade_log "server2 finished"
lounge_upgrade_log "start server3"
ssh root@server3 "yum --releasever=15 -y --disableplugin=presto,fastestmirror
distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server3.txt
lounge_upgrade_log "server3 finished"
lounge_upgrade_log "start server4"
ssh root@server4 "yum --releasever=15 -y --disableplugin=presto,fastestmirror
distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server4.txt
lounge_upgrade_log "server4 finished"
lounge_upgrade_log "start server5"
ssh root@server5 "yum --releasever=15 -y --disableplugin=presto,fastestmirror
distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server5.txt
lounge_upgrade_log "server5 finished"
lounge_upgrade_log "start server6"
ssh root@server6 "yum --releasever=15 -y --disableplugin=presto,fastestmirror
distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server6.txt
lounge_upgrade_log "server6 finished"
lounge_upgrade_log "start server7"
ssh root@server7 "yum --releasever=15 -y distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server7.txt
lounge_upgrade_log "server7 finished"
lounge_upgrade_log "start server8"
ssh root@server8 "yum --releasever=15 -y --disableplugin=presto,fastestmirror
distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server8.txt
lounge_upgrade_log "server8 finished"
lounge_upgrade_log "start server9"
ssh root@server9 "yum --releasever=15 -y --disableplugin=presto,fastestmirror
distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server9.txt
lounge_upgrade_log "server9 finished"
lounge_upgrade_log "start server10"
ssh root@server10 "yum --releasever=15 -y --disableplugin=presto,fastestmirror
distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server10.txt
lounge_upgrade_log "server10 finished"
lounge_upgrade_log "start server11"
ssh root@server11 "yum --releasever=15 -y --disableplugin=presto,fastestmirror
distro-sync 2>&1" | tee
/buildserver/dist-upgrade/log-server11.txt
lounge_upgrade_log "server11 finished"
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On 26/01/2012 12:46 PM, Reindl Harald wrote: i made several HUNDRED of dist-upgrades with yum since FC3 and upgrade via DVD/Preupgrade is simply UNACEPPTABLE i don't have any problems downloading a DvD, or a LiveCD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
Am 25.01.2012 23:48, schrieb Peter Robinson: > So I saw a rpm update and a number of other builds today when dealing > with various packaging bits. Checking the update [1] and reading the > attached bug [2] I was a little shocked to find that "yum upgrade" > between releases would be explicitly broken due to this feature. > > Yes, I know that it's not officially recommended as a means of > upgrading and never been QAed it has been generally supported and > expected to work [4] for as long as I can remember. if this is really true F17 will be even a bader release as F15 i made several HUNDRET of dist-upgrades with yum since FC3 and upgrade via DVD/Preupgrade is simply UNACEPPTABLE signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Wed, Jan 25, 2012 at 10:48:27PM +, Peter Robinson wrote: > Hi All, > > So I saw a rpm update and a number of other builds today when dealing > with various packaging bits. Checking the update [1] and reading the > attached bug [2] I was a little shocked to find that "yum upgrade" > between releases would be explicitly broken due to this feature. > > Yes, I know that it's not officially recommended as a means of > upgrading and never been QAed it has been generally supported and > expected to work [4] for as long as I can remember. > > The thing that is annoying me is that this change has not been > explicitly mentioned in the "Feature" [3], it does no appear in the > FAQ on the feature and I don't remember it ever being bought up in the > discussions about the feature although I admit I probably have missed > some of the discussion. Has this side effect of the feature been > discussed at all? Can someone point me to a thread? > https://fedorahosted.org/fesco/ticket/690#comment:8 https://fedorahosted.org/fpc/ticket/118 IIRC from the discussion in FPC meetings, there should be a way to make yum upgrades work but you'd first have to boot up specially and run an initial upgrade script: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 If the Feature Owners have progressed to the implementing stae, I would greatly appreciate them updating that page with the actual step-by-step to perform the upgrade (which will also allow people to test that things work). I also agree with your point that this discussion should be reflected on the Feature page (Since the Feature page is where marketing material is taken from). Could that be updated as well? -Toshio pgphmzPQrIGE5.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Am 30.10.2011 23:02, schrieb Lennart Poettering: > On Mon, 24.10.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote: > > Here's an attempt to summarize the rationale for merging /bin, /sbin, > /usr/sbin into /usr/bin with different words collecting the various points > raised: > > a) the split between sbin and bin requires psychic powers from >upstream developers: > >The simple fact is that moving binaries between these dirs is really >hard, and thus developers in theory would need to know at the time >they first introduce a binary whether it *ever* might ever make sense to >invoke it as unprivileged user (because in that case the binary >belongs in /bin, not /sbin). History shows that more often than >not developers have placed their stuff in the wrong directory, see >/sbin/arp, /sbin/ifconfig, /usr/sbin/httpd and then there is no smart >way to fix things anymore since changing paths means breaking all hardcoded >scripts. And hardcoding paths in scripts is actually something we >encourage due to perfomance reasons. The net effect is that many >upstream developers unconditionally place their stuff in bin, and >never consider sbin at all which undermines the purpose of sbin >entirely (i.e. in systemd we do not stick a single binary in sbin, >since we cannot be sure for any of its tools that it will never >ever be useful for non-root users. and systemd is as low-level, >system-specific it can get). > > b) The original definition of /sbin is fully obsolete (i.e. the "s" in >sbin stood originally for "static" binaries) > > c) /bin vs. /sbin is not about security, never has been. Doing this >would be security by obscurity, and pretty stupid, too. > > d) splitting /bin off /sbin is purely and only relevant for $PATH, and >$PATH is purely and only something to ease access to the tools in it >for shell users. The emphasis here is on "ease". It is not a way to >make it harder for users to access some tools. Or in other words: if >your intention is to hide certain tools from the user in order not to >confuse him, then there are much better places for that: the >documentation could document them in a separate section or so. I >don't think it makes any sense at all trying to educate the user by >playing games with what he can see if he presses TAB in the shell. On >top of that users who use the shell are the ones who react allergic >to this kind of attempts of forced education anyway. So just drop >this nonsense. > > e) the split between sbin/ and /bin is effectively made redundant already, >since both are listed in the $PATH of all users already since a >couple of Fedora versions. And due to d) the split hence has no >reason to exist, at all. > > f) splitting things up complicates stuff. If you want to keep things >separate you really need a good reason for that. We should always >focus on simplifiying things. And merging things into /usr does just >that: it drastically simplifies the complexities we have collected >over 30+ years of Unix heritage. > > g) given that some distros place certain binaries in other places than >others, merging the dirs has the big benefit that the four paths are >equivalent and scripts from other distros work on ours, regardless >where the other distros place their stuff > > h) the split between /usr and / was mostly about early boot >initialization: i.e. a minimal system was available in / which was >just good enough to find the full OS stuff in /usr. But that hasn't >worked in ages, and the discussion for split off /usr is over and the >install option got removed from anaconda (though you can still >install things like that by hand if you really want to shoot yourself >in the foot) > >http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > i) The separation between minimal boot system in / and full system in >/usr is obsoleted by initrd in a way: the new minimal boot system is >the initrd. Stacking multiple levels of "minimal boot system", one >after the other is a stupid game. So let's stick to the one we really >need which is initrd, and forget about the one that we don't need >anymore, and is broken since ages. > > j) having all static, distribution-provided, sharable OS stuff in a single dir >in /usr simplifies read-only setups drastically. I think we should >ensure that having the OS itself read-only is something that works >right-away without having to enable special modes that do this which >involves a ton of less-than-beautiful hacks. Being able to make the >libc and other core libraries fully read-only without also having to >make /etc read-only and without having to add a junkload of r/o bind >mounts is highly desirable. > > k) having all static, distro-specific, sharable OS in a single dir >makes snapshots of the
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Mon, 24.10.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote: Here's an attempt to summarize the rationale for merging /bin, /sbin, /usr/sbin into /usr/bin with different words collecting the various points raised: a) the split between sbin and bin requires psychic powers from upstream developers: The simple fact is that moving binaries between these dirs is really hard, and thus developers in theory would need to know at the time they first introduce a binary whether it *ever* might ever make sense to invoke it as unprivileged user (because in that case the binary belongs in /bin, not /sbin). History shows that more often than not developers have placed their stuff in the wrong directory, see /sbin/arp, /sbin/ifconfig, /usr/sbin/httpd and then there is no smart way to fix things anymore since changing paths means breaking all hardcoded scripts. And hardcoding paths in scripts is actually something we encourage due to perfomance reasons. The net effect is that many upstream developers unconditionally place their stuff in bin, and never consider sbin at all which undermines the purpose of sbin entirely (i.e. in systemd we do not stick a single binary in sbin, since we cannot be sure for any of its tools that it will never ever be useful for non-root users. and systemd is as low-level, system-specific it can get). b) The original definition of /sbin is fully obsolete (i.e. the "s" in sbin stood originally for "static" binaries) c) /bin vs. /sbin is not about security, never has been. Doing this would be security by obscurity, and pretty stupid, too. d) splitting /bin off /sbin is purely and only relevant for $PATH, and $PATH is purely and only something to ease access to the tools in it for shell users. The emphasis here is on "ease". It is not a way to make it harder for users to access some tools. Or in other words: if your intention is to hide certain tools from the user in order not to confuse him, then there are much better places for that: the documentation could document them in a separate section or so. I don't think it makes any sense at all trying to educate the user by playing games with what he can see if he presses TAB in the shell. On top of that users who use the shell are the ones who react allergic to this kind of attempts of forced education anyway. So just drop this nonsense. e) the split between sbin/ and /bin is effectively made redundant already, since both are listed in the $PATH of all users already since a couple of Fedora versions. And due to d) the split hence has no reason to exist, at all. f) splitting things up complicates stuff. If you want to keep things separate you really need a good reason for that. We should always focus on simplifiying things. And merging things into /usr does just that: it drastically simplifies the complexities we have collected over 30+ years of Unix heritage. g) given that some distros place certain binaries in other places than others, merging the dirs has the big benefit that the four paths are equivalent and scripts from other distros work on ours, regardless where the other distros place their stuff h) the split between /usr and / was mostly about early boot initialization: i.e. a minimal system was available in / which was just good enough to find the full OS stuff in /usr. But that hasn't worked in ages, and the discussion for split off /usr is over and the install option got removed from anaconda (though you can still install things like that by hand if you really want to shoot yourself in the foot) http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken i) The separation between minimal boot system in / and full system in /usr is obsoleted by initrd in a way: the new minimal boot system is the initrd. Stacking multiple levels of "minimal boot system", one after the other is a stupid game. So let's stick to the one we really need which is initrd, and forget about the one that we don't need anymore, and is broken since ages. j) having all static, distribution-provided, sharable OS stuff in a single dir in /usr simplifies read-only setups drastically. I think we should ensure that having the OS itself read-only is something that works right-away without having to enable special modes that do this which involves a ton of less-than-beautiful hacks. Being able to make the libc and other core libraries fully read-only without also having to make /etc read-only and without having to add a junkload of r/o bind mounts is highly desirable. k) having all static, distro-specific, sharable OS in a single dir makes snapshots of the OS independetly of its state and configuration truly atomic. In a btrfs world doing 5 snapshots of /lib, /lib64, /bin, /sbin and /usr instead of just one is not atomic, and hence racy, and ugly, and boooh! l) having
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Fri, 28.10.11 14:26, Zing (z...@fastmail.fm) wrote: > > On Fri, 28 Oct 2011 11:47:04 +0200, Harald Hoyer wrote: > > > Read the rpm snippet on the feature page, please. > > I just briefly browsed the feature page and the requirement on initramfs > piqued me. Maybe I'm wrong, but usrmove would then make fedora systems > from now on specifically require the use of an initramfs? Not too happy > with the loss of flexibility here if that's true. We do not support initrd-less boots at all right now on Fedora. It breaks SELinux and Plymouth and a couple of other things. [ I am actually quite interested to make things work without initrd again, and in F16 the SELinux situation at least has been fixed, with only Plymouth leaving, but this has never been an official release goal, just something I worked on with system. ] So, given that we currently don't support initrd-less boots at all I think the /usr move changes nothing in this regard for now. On top of that note that /usr split off and not mounted in initrd has been broken since ages, so there isn't any news in it anyway. http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Am 28.10.2011 16:26 schrieb "Zing" : > > On Fri, 28 Oct 2011 11:47:04 +0200, Harald Hoyer wrote: > > > Read the rpm snippet on the feature page, please. > > I just briefly browsed the feature page and the requirement on initramfs > piqued me. Maybe I'm wrong, but usrmove would then make fedora systems > from now on specifically require the use of an initramfs? Not too happy > with the loss of flexibility here if that's true. > only, if you want to have /usr on a separate partition -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Fri, 28 Oct 2011 11:47:04 +0200, Harald Hoyer wrote: > Read the rpm snippet on the feature page, please. I just briefly browsed the feature page and the requirement on initramfs piqued me. Maybe I'm wrong, but usrmove would then make fedora systems from now on specifically require the use of an initramfs? Not too happy with the loss of flexibility here if that's true. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
One thing I'm not clear on is when the switch between the initramfs and the actual / filesystem is performed. For instance, what does the user get if they boot single user? What do they get if they boot single user and /usr is on an nfs filesystem? -Toshio pgpC7SFu4zoLJ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Fri, Oct 28, 2011 at 11:47:04AM +0200, Harald Hoyer wrote: > On 10/27/2011 08:35 PM, Chris Adams wrote: > > The strategy is: > > - Replace binaries in /bin /sbin /usr/sbin /lib /lib64 with symlinks to > their counterpart in /usr. Symlinking is done in rpm %post. Symlinks are > part of the filelist with %ghost. > - As soon as one of these directories _only_ contains symlinks, it can > be removed completly and replaced by a symlink. > - The removal of the directories can either happen after the upgrade via > anaconda, or within the initramfs while booting or in shutdown. > - Fresh installations will get the toplevel symlinks immediatly and no > %ghost symlinks are created > > Read the rpm snippet on the feature page, please. > Ugh. So you're proposing that all package maintainers with programs or libraries in / will need to update their packages to carry the compat symlinks and you're proposing that replacing the / directories with symlinks has to be a special case outside of packaging itself? I'm sorry, for the question, it's just that neither of these were clear from reading the feature page. Perhaps if you add your middle two bullets from above to the Roadmap section it will be more clear. Also, your list of 257 packages is incomplete. For instance, you're missing bash. Linking the script that you use to generate the list to the Feature page would also be helpful. Thanks, Toshio pgppEwwD4eWHT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
This feature is going to cause a lot of churn. Aside from the huge changes within fedora I think a bigger issue will be downstream of fedora where third party packages and configs will require large changes. I would worry we might alienate our users a bit with this? Now I'm all for clean up, but sometimes it may have to be done piecemeal for pragmatic reasons. Could someone please enlighten me on the functional benefits of moving everything to /usr? I can see the clean up benefits of splitting things by mutability/persistence, with the proposed scheme being: /etc - non-shareable, can be read-only, host-only configuration /usr - shareable, can be read-only, package managed, binaries /var - non-shareable, writable, host-only state/data /run - temporary state However the existing hierarchy can be quite easily adjusted. For example I previously worked with a Fedora 14 system on installations of up to 1000 systems that were organized like: /tmp - temporary state (rw) (ram) /var - host state (rw) (nfs) /etc/dev - device state³ (rw) (local disk/flash etc.) /... - the rest¹ (ro²) (nfs) ¹ The rest was a single file system. I've never mounted /usr as a separate file system anyway. ² Note there were a few places in the rest of the hierarchy that needed to be bind mounted to the (rw) locations, but they were minimal and encapsulated in /etc/statetab.d/blah Also it seemed quite elegant in the case of /etc for example to have all the config together, with only a couple of places auto bind mounted to (rw). ³ Stuff like touchscreen calibration settings. Also about snapshots. This is possible (better?) when done from the source location. I.E. in my example above, the (ro) nfs directory was easily copied or directed to a new release directory. For local systems the equivalent would be doing a snapshot of the (ro) file system at the file system level (like BTRFS supports), rather than going down through the file hierarchy which seems inefficient and racy. cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/27/2011 08:35 PM, Chris Adams wrote: > Once upon a time, Chris Adams said: >> One big question though: can RPM handle such a change? IIRC, when the >> switch from /etc/rc.d/init.d to /etc/init.d was made, initially >> everything was going to be moved and the old paths symlinked for a few >> releases. However, there was some problem with RPM that couldn't handle >> switching an existing directory to a symlink, so that change was reduced >> to introducing /etc/init.d as a symlink. How will upgrades be handled >> if this feature goes through? > > I haven't seen this part addressed, and the more I think about it, the > more I think it may be a show-stopper for upgrades. > > IIRC the problem is that if there are any files in /bin, RPM can't > replace the directory with a symlink. There could be files from > third-party RPMs, Fedora RPMs that have been retired but people still > have installed, or from local changes/customizations. > > There is also a problem with the order things are done. RPM can't > replace /bin until all RPMs such as bash are updated to versions using > /usr/bin, but as soon as you install that bash, /bin/sh %post scripts > are broke until /bin is symlinked. > > For example, if you use the old-style network initialization (instead of > NM), the way to do pre/post config per interface is with > /sbin/ifup-pre-local and /sbin/ifup-local. If an admin has created > those files, RPM can't replace /sbin with a symlink to /usr/sbin AFAIK. > > This would also apply if somebody added firmware manually to > /lib/firmware or built a local kernel and installed modules to > /lib/modules. > > The only way I see to make this work would be to put a change directly > into anaconda (before it starts installing RPMs), but then you'd break > anybody that tried to "yum upgrade" from an older release (and there are > always people that do that). Any anaconda work-around for this would > also have to handle filename conflicts among locally-created files (e.g. > /bin/foo and /usr/bin/foo). > The strategy is: - Replace binaries in /bin /sbin /usr/sbin /lib /lib64 with symlinks to their counterpart in /usr. Symlinking is done in rpm %post. Symlinks are part of the filelist with %ghost. - As soon as one of these directories _only_ contains symlinks, it can be removed completly and replaced by a symlink. - The removal of the directories can either happen after the upgrade via anaconda, or within the initramfs while booting or in shutdown. - Fresh installations will get the toplevel symlinks immediatly and no %ghost symlinks are created Read the rpm snippet on the feature page, please. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Once upon a time, Chris Adams said: > One big question though: can RPM handle such a change? IIRC, when the > switch from /etc/rc.d/init.d to /etc/init.d was made, initially > everything was going to be moved and the old paths symlinked for a few > releases. However, there was some problem with RPM that couldn't handle > switching an existing directory to a symlink, so that change was reduced > to introducing /etc/init.d as a symlink. How will upgrades be handled > if this feature goes through? I haven't seen this part addressed, and the more I think about it, the more I think it may be a show-stopper for upgrades. IIRC the problem is that if there are any files in /bin, RPM can't replace the directory with a symlink. There could be files from third-party RPMs, Fedora RPMs that have been retired but people still have installed, or from local changes/customizations. There is also a problem with the order things are done. RPM can't replace /bin until all RPMs such as bash are updated to versions using /usr/bin, but as soon as you install that bash, /bin/sh %post scripts are broke until /bin is symlinked. For example, if you use the old-style network initialization (instead of NM), the way to do pre/post config per interface is with /sbin/ifup-pre-local and /sbin/ifup-local. If an admin has created those files, RPM can't replace /sbin with a symlink to /usr/sbin AFAIK. This would also apply if somebody added firmware manually to /lib/firmware or built a local kernel and installed modules to /lib/modules. The only way I see to make this work would be to put a change directly into anaconda (before it starts installing RPMs), but then you'd break anybody that tried to "yum upgrade" from an older release (and there are always people that do that). Any anaconda work-around for this would also have to handle filename conflicts among locally-created files (e.g. /bin/foo and /usr/bin/foo). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On Thu, Oct 27, 2011 at 02:51, Kay Sievers wrote: > On Thu, Oct 27, 2011 at 10:46, Harald Hoyer wrote: >> 4.6. /usr/lib : Libraries for programming and packages >> >> 4.6.1. Purpose >> >> /usr/lib includes object files and libraries. ^[22] On some systems, it >> may also include internal binaries that are not intended to be executed >> directly by users or shell scripts. ^[23] > > /usr/lib// is the preferred way to do it. Udev does this > since forever, and systemd does the same. LSB itself uses > /usr/lib/lsb/. > > I think 'libexec' is just a weird name, and should be faded out over > time. Fedora was the only major distro which used that, it never > existed on other distributions, and we want less needless differences > here. I believe it was a GNUism or BSDism from the early 1990's.. I remember seeing libexec in Makefiles and autoconf's from time immemorial (circa 1994?) as its use was two fold: 1) Remove binaries from /usr/lib in the same way /sbin removed items from /etc 2) Speed up ld search times on *n*x's that searched linearly through the directory for symbols. IIRC Red Hat used it because we were trying to be friendly with FSF complaints way back in the day and patching all the code to not use it was more time consuming than the 4 developers wanted to deal with. Debian didn't use it for the same reason (they were in a tif with FSF at the time, and patching it showed they were independent.) In any case that is the most likely historical reason for it. If you really want to get rid of it.. might as well start looking at building a LOT of patches. > What we want for sane packaging is an 'application private directory' > not something just for executables. Application configuration like > udev rules or systemd service files (init scripts) need to live in > that directory too, and 'libexec' really doesn't sound right for that. > > Kay > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Let us be kind, one to another, for most of us are fighting a hard battle." -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On Thu, Oct 27, 2011 at 10:34:45AM +0200, Harald Hoyer wrote: > On 10/26/2011 06:21 PM, Toshio Kuratomi wrote: > > In context, at least, this is wrong advice as it's a violation of the FHS: > > > > http://pathname.com/fhs/pub/fhs-2.3.html#PURPOSE22 > > > > """ > > Purpose > > /usr/lib includes object files, libraries, and internal binaries that are > > not intended to be executed directly by users or shell scripts. > > [..] > > Specific Options > > > > For historical reasons, /usr/lib/sendmail must be a symbolic link to > > /usr/sbin/sendmail if the latter exists. > > """ > > > > The daemons and such were in places like /usr/lib to begin with. This was > > deemed to be the wrong place for them. Instead they were placed into /sbin. > > > > You may be quibbling over the use of "shell scripts" in that section as you > > might think that daemons aren't run from shell scripts in systemd and that > > illustrates that shell scripts were only an implementation detail in sysv. > > In doing so, however, you miss out on "internal binaries". A daemon > > executable is the public entry point into a service so they aren't internal. > > > > -Toshio > > > > And I want to point to > http://pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1394 , which you omitted: > > Applications may use a single subdirectory under /usr/lib. If an > application uses a subdirectory, all architecture-dependent data > exclusively used by the application must be placed within that > subdirectory. [23] > I may have omitted it but I did not fail to read and understand it. The FHS is here specifying that architecture-dependent *data* may live in /ust/lib. You want to move programs there. Programs are only specified in the section I quoted earlier about "internal binaries". -Toshio pgpQWz1hozDTt.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/27/2011 03:01 PM, Phil Knirsch wrote: > On 10/27/2011 11:00 AM, Harald Hoyer wrote: >> On 10/26/2011 09:05 PM, Adam Williamson wrote: >>> On Wed, 2011-10-26 at 15:40 +0200, Harald Hoyer wrote: On 10/24/2011 08:05 PM, Chris Adams wrote: >> === >> #fedora-meeting: FESCO (2011-10-24) >> === >> * Discussion about https://fedoraproject.org/wiki/Features/UsrMove >> (t8m, 17:26:45) > Sometimes you have to clean up your room and tidy up the mess, which piled up over time. This cleanup can be done on one day and checked in by one person. It's not rocket science! It does not break anything, because the compat symlinks will _not_ go away. >>> >>> Every time someone says this, something winds up breaking anyway, >>> because of some kind of oddness like situations where the symlinks >>> aren't read or become recursive, or selinux issues (always a fun one)! >> >> I am running my F16 system with all these symlinks now for quiet a >> while. Despite the consolehelper symlinks, I have not encountered any >> problem. Even rpm updates seem to work fine. But I agree, the devil is >> in the detail, and we surely will find something, which does not work. >> But I don't think, these problems are severe and not easily fixable. > > If you already have a system running that way how about if you put > together a document how to do this and let other people or even Fedora > QA test it out and run it through their testsuits? > > That way we'd have a lot more eyes on it, could spot issues with it much > faster and could get the whole idea a solid ground before it's widely > introduced to Fedora and everything would already have been prepared for > it, avoiding exactly those possibly missed oddball or exotic scenarios. > > Just my $0.02 after seeing you eating your own dogfood first (, > grosss! ;))). > > Thanks & regards, Phil > 1. create a dracut initramfs with a bash as the standard shell # dracut -o dash -f 2. reboot 3. Add "rd.break rd.shell" to the kernel command line and you are dropped to the dracut shell. # mount -o remount,rw /sysroot beware not to start paths with / or just prefix them with /sysroot - remove the consolehelper symlinks in /sysroot/usr/bin - move stuff to /sysroot/usr/bin from /sysroot/bin /sysroot/sbin sysroot/usr/sbin - move stuff from /sysroot/lib* to /sysroot/usr/lib* - remove the old dirs - create the _relative_ symlinks # mount -o remount,ro /sysroot 4. exit dracut # exit Then you should be booted into your changed system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/27/2011 11:00 AM, Harald Hoyer wrote: > On 10/26/2011 09:05 PM, Adam Williamson wrote: >> On Wed, 2011-10-26 at 15:40 +0200, Harald Hoyer wrote: >>> On 10/24/2011 08:05 PM, Chris Adams wrote: > === > #fedora-meeting: FESCO (2011-10-24) > === > * Discussion about https://fedoraproject.org/wiki/Features/UsrMove >(t8m, 17:26:45) >>> >>> >>> Sometimes you have to clean up your room and tidy up the mess, which >>> piled up over time. This cleanup can be done on one day and checked in >>> by one person. It's not rocket science! It does not break anything, >>> because the compat symlinks will _not_ go away. >> >> Every time someone says this, something winds up breaking anyway, >> because of some kind of oddness like situations where the symlinks >> aren't read or become recursive, or selinux issues (always a fun one)! > > I am running my F16 system with all these symlinks now for quiet a > while. Despite the consolehelper symlinks, I have not encountered any > problem. Even rpm updates seem to work fine. But I agree, the devil is > in the detail, and we surely will find something, which does not work. > But I don't think, these problems are severe and not easily fixable. If you already have a system running that way how about if you put together a document how to do this and let other people or even Fedora QA test it out and run it through their testsuits? That way we'd have a lot more eyes on it, could spot issues with it much faster and could get the whole idea a solid ground before it's widely introduced to Fedora and everything would already have been prepared for it, avoiding exactly those possibly missed oddball or exotic scenarios. Just my $0.02 after seeing you eating your own dogfood first (, grosss! ;))). Thanks & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Supervisor Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On 10/27/2011 07:52 AM, David Tardon wrote: > On Wed, Oct 26, 2011 at 03:23:55PM +0200, Ralf Corsepius wrote: >> >> Besides this, one may have the opinion, that no binaries should be >> allowed in /usr/lib/. Fedora never enforced this rule, because RH has a >> tradition of being sloppy wrt. /usr/lib/. > > One may also have the opinion that you voiced your anti-RH attitude > often enough. Rubbish, I do not have an anti-RH attitude. It's just that there are people on RH's payrole, of whom I feel are abusing their position @RH. I also feel that RH often presses through decisions and immature, questionable piece of SW in ways, I consider to be violent. Besides this, wrt. my sentence above - RH distros ever since they are around, have been using /usr/lib/ as "last escape to the FHS". It's a RH tradition, nothing more, nothing less - It doesn't strctly comply to the FHS, but it doesn't hurt much in most cases. > Seriously, anyone reading this list already knows that if > a guy from Red Hat does something, whatever it may be, you are against > it. Well, this is a misperception - I am remaining silent on the vast majority of occasions and only become vocal when I feel things are derailing and/or regressing. It's just that RH very often is involved in leading roles of such incidents and that Fedora often is proud of cases. This doesn't mean by any means, I hate RH or I think "all @RHs are assholes". RH is a big enterprise, so they inevitably have people with all kinds of attitudes and skills on their payrole - Rest assured, the vast majority is doing an excellent job, but there are a few who do not. But ... this "UsrMove" feature ... with all due respect, I was shocked when reading it. To me, this proposal is the silliest and dumbest thing, I have ever seen being proposed in Fedora. > That said, I am eagerly awaiting your patches that make libreoffice use > FHS instead of placing everything into /usr/lib/libreoffice. Pardon, but are you expecting _me_ to do _your_ job? Should time permit, I may check which steps would be required to make libreoffice more FHS compliant, but my contingent of _spare time_, I have available for Fedora already is overdrawn. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On Thu, Oct 27, 2011 at 10:51, David Tardon wrote: > On Thu, Oct 27, 2011 at 10:38:15AM +0200, Michal Hlavinka wrote: >> On 10/27/2011 10:34 AM, Harald Hoyer wrote: >> >> That would also mean that libreoffice (using /usr/lib*/libreoffice) >> should have all binaries there? I guess not. > > It has always been that way. There are only shell scripts in /usr/bin. > (Moreover, the /usr/lib*/libreoffice/program/soffice called from > /usr/bin/libreoffice is another shell script that execs the real > binary.) Ideally, all 64bit libraries it installs would be in /usr/lib64/libreoffice/*, and all text files, java archives and executables (and possibly 32 bit libraries) live in /usr/lib/libreoffice/*. The lib64 directory is in theory reserved for shared libs only, and not suppossed to contain anything else. I don't know about the specifics of libreoffice, but multilib can be a real mess in the real world. Most complex apps can't really mix 32 and 64 bit data and binaries, even when they theoretically run fine on the architecture. So the current packaging seems like the best compromise. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/26/2011 09:05 PM, Adam Williamson wrote: > On Wed, 2011-10-26 at 15:40 +0200, Harald Hoyer wrote: >> On 10/24/2011 08:05 PM, Chris Adams wrote: === #fedora-meeting: FESCO (2011-10-24) === * Discussion about https://fedoraproject.org/wiki/Features/UsrMove (t8m, 17:26:45) >>> >> >> >> Sometimes you have to clean up your room and tidy up the mess, which >> piled up over time. This cleanup can be done on one day and checked in >> by one person. It's not rocket science! It does not break anything, >> because the compat symlinks will _not_ go away. > > Every time someone says this, something winds up breaking anyway, > because of some kind of oddness like situations where the symlinks > aren't read or become recursive, or selinux issues (always a fun one)! I am running my F16 system with all these symlinks now for quiet a while. Despite the consolehelper symlinks, I have not encountered any problem. Even rpm updates seem to work fine. But I agree, the devil is in the detail, and we surely will find something, which does not work. But I don't think, these problems are severe and not easily fixable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On Thu, Oct 27, 2011 at 10:46, Harald Hoyer wrote: > 4.6. /usr/lib : Libraries for programming and packages > > 4.6.1. Purpose > > /usr/lib includes object files and libraries. ^[22] On some systems, it > may also include internal binaries that are not intended to be executed > directly by users or shell scripts. ^[23] /usr/lib// is the preferred way to do it. Udev does this since forever, and systemd does the same. LSB itself uses /usr/lib/lsb/. I think 'libexec' is just a weird name, and should be faded out over time. Fedora was the only major distro which used that, it never existed on other distributions, and we want less needless differences here. What we want for sane packaging is an 'application private directory' not something just for executables. Application configuration like udev rules or systemd service files (init scripts) need to live in that directory too, and 'libexec' really doesn't sound right for that. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On Thu, Oct 27, 2011 at 10:38:15AM +0200, Michal Hlavinka wrote: > On 10/27/2011 10:34 AM, Harald Hoyer wrote: > > That would also mean that libreoffice (using /usr/lib*/libreoffice) > should have all binaries there? I guess not. It has always been that way. There are only shell scripts in /usr/bin. (Moreover, the /usr/lib*/libreoffice/program/soffice called from /usr/bin/libreoffice is another shell script that execs the real binary.) D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On 10/27/2011 10:34 AM, Harald Hoyer wrote: > On 10/26/2011 06:21 PM, Toshio Kuratomi wrote: >> On Wed, Oct 26, 2011 at 03:18:42PM +0200, Harald Hoyer wrote: >>> On 10/26/2011 03:07 PM, Chris Adams wrote: Once upon a time, Richard W.M. Jones said: > Having said that, the split between /sbin and /bin is not a truly > historical one, ie. it didn't exist in V7. I think it was added by > System V which did a lot of other strange stuff too. Well, historically, a bunch of system utilities were in odd places like /etc and /usr/lib. The idea of /sbin and /usr/sbin was to get compiled executables out of those places (and to not clutter up the "normal" bin directories with stuff users didn't need). >>> >>> For daemons, which should not be called directly on the command line, I >>> would suggest to move them to /usr/lib// anyway. >>> >> In context, at least, this is wrong advice as it's a violation of the >> FHS: >> >> http://pathname.com/fhs/pub/fhs-2.3.html#PURPOSE22 >> >> """ >> Purpose >> /usr/lib includes object files, libraries, and internal binaries that are >> not intended to be executed directly by users or shell scripts. >> [..] >> Specific Options >> >> For historical reasons, /usr/lib/sendmail must be a symbolic link to >> /usr/sbin/sendmail if the latter exists. >> """ >> >> The daemons and such were in places like /usr/lib to begin with. This was >> deemed to be the wrong place for them. Instead they were placed into >> /sbin. >> >> You may be quibbling over the use of "shell scripts" in that section >> as you >> might think that daemons aren't run from shell scripts in systemd and >> that >> illustrates that shell scripts were only an implementation detail in >> sysv. >> In doing so, however, you miss out on "internal binaries". A daemon >> executable is the public entry point into a service so they aren't >> internal. >> >> -Toshio >> > > And I want to point to > http://pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1394 , which you omitted: > > Applications may use a single subdirectory under /usr/lib. If an > application uses a subdirectory, all architecture-dependent data > exclusively used by the application must be placed within that > subdirectory. [23] > > Ok, found a cached version of FHS-3: http://webcache.googleusercontent.com/search?q=cache:GIn-hmSAjL0J:dev.linuxfoundation.org/~licquia/fhs-3.0-drafts/fhs.txt+site:http://dev.linuxfoundation.org/%257Elicquia/fhs-3.0-drafts/&hl=en&strip=1 4.6. /usr/lib : Libraries for programming and packages 4.6.1. Purpose /usr/lib includes object files and libraries. ^[22] On some systems, it may also include internal binaries that are not intended to be executed directly by users or shell scripts. ^[23] Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. ^[24] 4.6.2. Specific Options For historical reasons, /usr/lib/sendmail must be a symbolic link which resolves to the sendmail-compatible command provided by the system's mail transfer agent, if the latter exists. ^[25] ^[26] 4.7. /usr/libexec : Binaries run by other programs (optional) 4.7.1. Purpose /usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/libexec. Applications which use /usr/libexec in this way must not also use /usr/lib to store internal binaries, though they may use /usr/lib for the other purposes documented here. Rationale Some previous versions of this document did not support /usr/libexec, despite it being standard practice in a number of environments. ^[27] To accomodate this restriction, it became common practice to use /usr/lib instead. Either practice is now acceptable, but each application must choose one way or the other to organize itself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On 10/27/2011 10:34 AM, Harald Hoyer wrote: > On 10/26/2011 06:21 PM, Toshio Kuratomi wrote: >> On Wed, Oct 26, 2011 at 03:18:42PM +0200, Harald Hoyer wrote: >>> On 10/26/2011 03:07 PM, Chris Adams wrote: Once upon a time, Richard W.M. Jonessaid: > Having said that, the split between /sbin and /bin is not a truly > historical one, ie. it didn't exist in V7. I think it was added by > System V which did a lot of other strange stuff too. Well, historically, a bunch of system utilities were in odd places like /etc and /usr/lib. The idea of /sbin and /usr/sbin was to get compiled executables out of those places (and to not clutter up the "normal" bin directories with stuff users didn't need). >>> >>> For daemons, which should not be called directly on the command line, I >>> would suggest to move them to /usr/lib// anyway. >>> >> In context, at least, this is wrong advice as it's a violation of the FHS: >> >> http://pathname.com/fhs/pub/fhs-2.3.html#PURPOSE22 >> >> """ >> Purpose >> /usr/lib includes object files, libraries, and internal binaries that are >> not intended to be executed directly by users or shell scripts. >> [..] >> Specific Options >> >> For historical reasons, /usr/lib/sendmail must be a symbolic link to >> /usr/sbin/sendmail if the latter exists. >> """ >> >> The daemons and such were in places like /usr/lib to begin with. This was >> deemed to be the wrong place for them. Instead they were placed into /sbin. >> >> You may be quibbling over the use of "shell scripts" in that section as you >> might think that daemons aren't run from shell scripts in systemd and that >> illustrates that shell scripts were only an implementation detail in sysv. >> In doing so, however, you miss out on "internal binaries". A daemon >> executable is the public entry point into a service so they aren't internal. >> >> -Toshio >> > > And I want to point to > http://pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1394 , which you omitted: > > Applications may use a single subdirectory under /usr/lib. If an > application uses a subdirectory, all architecture-dependent data > exclusively used by the application must be placed within that > subdirectory. [23] That would also mean that libreoffice (using /usr/lib*/libreoffice) should have all binaries there? I guess not. I can be wrong, but "used by the application" seems different from "application itself". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On 10/26/2011 06:21 PM, Toshio Kuratomi wrote: > On Wed, Oct 26, 2011 at 03:18:42PM +0200, Harald Hoyer wrote: >> On 10/26/2011 03:07 PM, Chris Adams wrote: >>> Once upon a time, Richard W.M. Jones said: Having said that, the split between /sbin and /bin is not a truly historical one, ie. it didn't exist in V7. I think it was added by System V which did a lot of other strange stuff too. >>> >>> Well, historically, a bunch of system utilities were in odd places like >>> /etc and /usr/lib. The idea of /sbin and /usr/sbin was to get compiled >>> executables out of those places (and to not clutter up the "normal" bin >>> directories with stuff users didn't need). >> >> For daemons, which should not be called directly on the command line, I >> would suggest to move them to /usr/lib// anyway. >> > In context, at least, this is wrong advice as it's a violation of the FHS: > > http://pathname.com/fhs/pub/fhs-2.3.html#PURPOSE22 > > """ > Purpose > /usr/lib includes object files, libraries, and internal binaries that are > not intended to be executed directly by users or shell scripts. > [..] > Specific Options > > For historical reasons, /usr/lib/sendmail must be a symbolic link to > /usr/sbin/sendmail if the latter exists. > """ > > The daemons and such were in places like /usr/lib to begin with. This was > deemed to be the wrong place for them. Instead they were placed into /sbin. > > You may be quibbling over the use of "shell scripts" in that section as you > might think that daemons aren't run from shell scripts in systemd and that > illustrates that shell scripts were only an implementation detail in sysv. > In doing so, however, you miss out on "internal binaries". A daemon > executable is the public entry point into a service so they aren't internal. > > -Toshio > And I want to point to http://pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1394 , which you omitted: Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. [23] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On Wed, Oct 26, 2011 at 03:23:55PM +0200, Ralf Corsepius wrote: > > Besides this, one may have the opinion, that no binaries should be > allowed in /usr/lib/. Fedora never enforced this rule, because RH has a > tradition of being sloppy wrt. /usr/lib/. One may also have the opinion that you voiced your anti-RH attitude often enough. Seriously, anyone reading this list already knows that if a guy from Red Hat does something, whatever it may be, you are against it. So, your general disagreemeent with anything Red Hat being a well-established fact (I would even say axiom), you can as well save yourself the effort of writing further emails to that end (which will save the rest of the recipients of this list the effort of reading them). That said, I am eagerly awaiting your patches that make libreoffice use FHS instead of placing everything into /usr/lib/libreoffice. The installer is written in perl, so you should not have any problem with it. You may need to change other parts of code as well, but I am prepared to offer suggestions. I am also prepared to help you with getting the patches to upstream. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Wed, 26 Oct 2011 15:40:41 +0200, Harald Hoyer wrote: > With the compat symlinks, you even have no path problems anymore with > any alien scripts you run. I wouldn't say no path problems. I'm sure you know that symlinks can cause traversal problems (e.g. the ".." doesn't take you where you thought it would.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
