From Fedora Project Wiki

< FWN‎ | Beats

(pass 1 devel #174)
 
(15 intermediate revisions by the same user not shown)
Line 7: Line 7:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Fedora 11 Preview Xorg "Lock-up" ===
=== Would You Like to Write This Beat ? ===


[[AndyLawrence|DrDiesel]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02425.html</ref> an Xorg lockup with a fully updated <code>Fedora 11 Preview</code> on 2009-04-28 whenever he visited a particular webpage. Subsequent confirmation from other testers led<ref>http://bugzilla.redhat.com/show_bug.cgi?id=498131</ref> to a bugzilla report. It intially appeared to be a soft lock according to some comments on the bug which reported the ability to move the mouse cursor and play music.  
Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or [[User:Pcalarco|Pascal Calarco]]. A short overview of what you may need to do can be obtained by reading the workflow<ref>http://fedoraproject.org/wiki/FWN/WorkFlow</ref> section of the wiki. The @fedora-news list is also extremely open and helpful. Joining<ref>http://fedoraproject.org/wiki/FWN/NewsProject/Join</ref> the News Project is quite straightforward.


Some very helpful contributions from [[AdamJackson|Adam Jackson]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02452.html</ref> that the problem was due to a ridiculously large blit<ref>http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork#head-e39a838dc80e85fcd06dda71ffef534a5526444d-2</ref> exposing mis-handling of video memory mapping by the kernel. Adam laid<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02487.html</ref> the blame squarely on the mis-coding of the web-page. He added that this was not actually a lock-up, just agonizingly slow rendering. RichardKörber requested further help in debugging this and similar problems and that request led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02468.html</ref> to a nice, succinct recipe for generating <code>gdb</code> backtraces.
<references/>


<references/>
=== Is gNaughty a Hot Babe ? ===
 
[[User:Sundaram|Rahul Sundaram]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html</ref> the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.


=== Presto No Go ===
One interesting point is that CMUCL<ref>One of the Common Lisp implementations: http://www.cons.org/cmucl/</ref> was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html</ref> to be only available for 32-bit systems. However what got people really excited was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html</ref> Rahul's question about what to do concerning the <code>gNaughty</code> package. Its sole purpose seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html</ref> to be downloading pornography. Rahul referenced the <code>hot-babe</code> CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity.  Rahul wanted to find out "[...] is this allowed in Fedora?"


Unfortunately it appears that <code>Presto</code>, the near miraculous bandwidth saving <code>YUM</code> plugin<ref>http://fedoraproject.org/wiki/Releases/FeaturePresto</ref>, will not be an official part of <code>Fedora 11</code> due to infrastructure issues cited<ref>http://paul.frields.org/?p=1611</ref> by [[User:Pfrields|Paul W. Frields]]. This is contrary to what we reported<ref>http://fedoraproject.org/wiki/FWN/Issue172#Presto_and_DeltaRPM_Status</ref> in FWN#172.
Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html</ref> by [[User:Alsadi|Muayyad AlSadi]] who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. [[User:Notting|Bill Nottingham]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html</ref> skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html</ref> the reaction typified by [[User:Skvidal|Seth Vidal]] which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. [[User:bochcecha|Mathieu Bridon]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html</ref> that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy.


<references/>
<references/>


=== Fedora 12 Changes to GConf and intltool ===
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


[[User:Mclasen|Matthias Clasen]] requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02386.html</ref> feedback on changes in the way sechma translations were handled in <code>GConf</code> and <code>intltool</code>: ly, translations were merged by intltool from .po files into schemas files and then copied by gconftool from the schemas file into the database.  Now, translations are kept in .po files, and intltool only copies the gettext domain into the schemas, and further into the GConf database.  The only tool that ever uses these translations, gconf-editor, knows how to get them from the message catalogs.  The big advantage of this change is that schemas shrink radically, which should help a lot with the 'slow updates due to GConf' problem. It also reduces the redundancy of storing the schema translations in three places, which should help with live cd size."
[[KristapsViesalgs|Kristaps Viesalgs]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html</ref> for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"


It seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02396.html</ref> that all GConf-using applications will be rebuilt before <code>Fedora 12</code> ships but that there is no immediate rush to do so.
[[User:Ajax|Adam Jackson]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html</ref> for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by [[User:Adamwill|Adam Williamson]] and [[User:|Xavier Bachelot]]. The latter asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html</ref> any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.  


<references/>
<references/>


=== Ext4 fallocate() Happiness ===
=== Who Wants a Pony? ===


[[EricSandeen|Eric Sandeen] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02259.html</ref> that it would be useful to speed the adoption of the preallocation features of the <code>ext4</code> filesystem. (See FWN#170<ref>http://fedoraproject.org/wiki/FWN/Issue170#fallocate.282.29_Preferred_Glibc_Interface_for_Preallocation_.3F</ref> for previous coverage.) Eric provided a concise, informative description of what preallocation is and how it can be used: "One big feature that has already been brought up on the list[1] is file preallocation, which allows an application to pre-allocate blocks it knows that it will eventually write into, thereby making sure it won't run out of space, and also generally getting a more efficient/contiguous file layout.  Only a few applications are taking advantage of this so far, in part because it's new.[2]  The transmission bittorrent client is using it, but only if you tweak a configfile in (IMHO) non-obvious ways."
[[User:Kushal|Kushal Das]] promised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html</ref> a pony to anyone that would take the trouble to review<ref>http://bugzilla.redhat.com/show_bug.cgi?id=503021</ref> one of his packages.


A list of possible starting points to get more applications using preallocation was also provided.
<references/>


In response to some skepticism from [[TomLane|Tom Lane]] further explanation of which sorts of applications might benefit from preallocation was shared<ref></ref> by Eric: "You wouldn't want to use it for every little file you write, either.  But for some cases it can be a big win.  Torrent downloading?  This is sort of the quintessential case where it can help.  Databases?  yes.  Rsyncing large files?  yep.  Creating virtual images? yep.  Helping samba cope with weird windows client behavior?  yep Basically anything that is filled in over time, or filled in sparsely, could potentially benefit." Further questioning by [[MichaelCronenworth|Michael Cronenworth]] on the value of using <code>ext4</code> as opposed to <code>xfs</code> yielded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02309.html</ref> further interesting details.
=== Firestarter Retired as Unportable to PolicyKit ===


It seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02285.html</ref> that the <code>libvirt</code> developers had already jumped at the opportunity thanks to a patch provided<ref>http://www.amitshah.net/2009/03/comparison-of-file-systems-and-speeding.html</ref> by Amit Shah.
[[User:Maxamillion|Adam Miller]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html</ref> whether he should just retire the <code>Firestarter</code><ref>Firestarter is a firewall configuration GUI</ref> package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate <code>Firestarter</code> with <code>PolicyKit</code>. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok <code>PolicyKit</code>.


Following confirmation from [[User:Sundaram|Rahul Sundaram]] and [[User:Skvidal|Seth Vidal]] a decision was made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html</ref> by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."
A further suggestion from "Cry" prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html</ref> Adam to start filing RFEs against <code>system-config-firewall</code> for any features present in <code>Firestarter</code> but missing in <code>system-config-firewall</code>.
<references/>
<references/>


=== NetworkManager in Fedora 11 Preview ===
=== Russian Fedora ? ===


MarkBidewell wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02457.html</ref> why his sole network interface was inactivated automatically following a fresh install of <code>Fedora 11 Preview</code>.
When [[User:Peter|Peter Lemenkov]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html</ref> about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. [[User:Kkofler|Kevin Kofler]] gave<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html</ref> an able summary why this would still present Red Hat with a problem.


DanWilliams explained<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02461.html</ref> that this was a logical result of <code>anaconda</code> writing either <pre>"ONBOOT=no"</pre> if the install was not over a network or else <pre>"ONBOOT=yes"</pre> if the install was over a network. Dan explained that this was in part a security policy decision.
An assertion by [[User:|Alexey Torkhov]] that there existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html</ref> a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from [[User:Sundaram|Rahul Sundaram]].
 
Later Dan suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02484.html</ref> using <code>nm-connection-editor</code> to correctly <pre>/etc/sysconfig/network-scripts/ifcfg-*</pre> for both wired and wireless connections.


<references/>
<references/>


=== Moblin2 Mostly Fedora-derived ? ===
=== Will FESCo Revisit Kmods ? ===


[[MatthewGarrett|Matthew Garrett]] picked up<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00157.html</ref> on an older discussion about the extent to which <code>Moblin2</code> could be considered a derivative of Fedora. Matthew's conclusion was that most of the packages were "[...] identical to the Fedora package or is a simple mechanical transformation of a Fedora package[.]" A significant number of the patches were mostly derived from Fedora or SuSE also.
A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]].


<references/>
[[User:Adamwill|Adam Williamson]] and [[User:Mdomsch|Matt Domsch]] (Dell's DKMS mastermind) kicked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html</ref> some ideas back and forth over the advantages of <code>akmods</code> versus <code>kmods</code>.
 
=== Fedora 12: How to use DBUS for Terminal Sessions ? ===
 
[[DanWalsh|Dan Walsh]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00030.html</ref> for help in running a dbus session upon login to terminals so that he could run <code>restorecond</code> as a system service rather than a user service: "I want to run it under the Users UID and under with the users context.  Then I can have it watch for creation of files in the users home directory and be the equivalent of running restorecon ~/ by the user."
 
[[SteveGrubb|Steve Grubb]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00066.html</ref> worried that this would disrupt the audit trail and suggested a <code>PAM</code> session module instead. [[User:Bwolf|Bruno Wolff III]] also was disturbed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00068.html</ref> by the idea: "This seems to increase the risk of hostile apps being able to get executables relabelled to something they couldn't do directly."


<references/>
<references/>


=== PulseAudio Flamewar Continues ===
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===
 
The fallout from last week's thermonuclear flamewar continued<ref>http://fedoraproject.org/wiki/FWN/Issue173#PulseAudio:_A_Hearty_and_Robust_Exchange_of_Ideas</ref> to splatter downwards. Among the hotspots were: a thread in which [[User:Jgudmundsson|Johan B. Gudmundsson]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02198.html</ref> some way in which there would be no privileged default desktop spin;
 
[[User:Notting|Bill Nottingham]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00035.html</ref> that slamming the PulseAudio team for closing bugs WONTFIX was inaccurate.


It seems that perhaps <code>pavucontrol</code> may be one way to change the relative volume of individual applications (as per a question posed my [[MatthewWoehlke|Matthew Woehlke]] and echoed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00094.html</ref> by [[User:Pfrields|Paul W. Frields]]. [[LennartPoettering|Lennart Poettering]] stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00099.html</ref>, however, that <code>pavucontrol</code> should be removed.
Following a report from [[UweKiewel|Uwe Kiewel]] that a <pre>yum upgrade</pre> had spewed all sorts of errors the supported methods for upgrades were re-stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html</ref> by [[User:Adamwill|Adam Williamson]]: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."


<references/>
<references/>

Latest revision as of 01:15, 1 June 2009

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Would You Like to Write This Beat ?

Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or Pascal Calarco. A short overview of what you may need to do can be obtained by reading the workflow[1] section of the wiki. The @fedora-news list is also extremely open and helpful. Joining[2] the News Project is quite straightforward.

  1. ↑ http://fedoraproject.org/wiki/FWN/WorkFlow
  2. ↑ http://fedoraproject.org/wiki/FWN/NewsProject/Join

Is gNaughty a Hot Babe ?

Rahul Sundaram posted[1] the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.

One interesting point is that CMUCL[2] was revealed[3] to be only available for 32-bit systems. However what got people really excited was[4] Rahul's question about what to do concerning the gNaughty package. Its sole purpose seemed[5] to be downloading pornography. Rahul referenced the hot-babe CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?"

Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised[6] by Muayyad AlSadi who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. Bill Nottingham was[7] skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was[8] the reaction typified by Seth Vidal which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. Mathieu Bridon thought[9] that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html
  2. ↑ One of the Common Lisp implementations: http://www.cons.org/cmucl/
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html
  4. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html
  5. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html
  6. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html
  7. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html
  8. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html
  9. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html

Chrome9 Vx800 Graphics Support on LiveUSB

Kristaps Viesalgs asked[1] for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"

Adam Jackson asked[2] for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by Adam Williamson and [[User:|Xavier Bachelot]]. The latter asked[3] any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html

Who Wants a Pony?

Kushal Das promised[1] a pony to anyone that would take the trouble to review[2] one of his packages.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html
  2. ↑ http://bugzilla.redhat.com/show_bug.cgi?id=503021

Firestarter Retired as Unportable to PolicyKit

Adam Miller asked[1] whether he should just retire the Firestarter[2] package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate Firestarter with PolicyKit. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok PolicyKit.

Following confirmation from Rahul Sundaram and Seth Vidal a decision was made[3] by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."

A further suggestion from "Cry" prompted[4] Adam to start filing RFEs against system-config-firewall for any features present in Firestarter but missing in system-config-firewall.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html
  2. ↑ Firestarter is a firewall configuration GUI
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html
  4. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html

Russian Fedora ?

When Peter Lemenkov asked[1] about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. Kevin Kofler gave[2] an able summary why this would still present Red Hat with a problem.

An assertion by [[User:|Alexey Torkhov]] that there existed[3] a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from Rahul Sundaram.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html

Will FESCo Revisit Kmods ?

A discussion of why VirtualBox will not be a feature due to its code not yet heading upstream and consequently remaining as kmods drew a statement of support from Kevin Kofler for reverting the current banning of kmods should he become a FESCo member. Upon request from Richard W.M. Jones for a dispassionate summary of the reasons to avoid kmods drew[1] a concise response from Seth Vidal.

Adam Williamson and Matt Domsch (Dell's DKMS mastermind) kicked[2] some ideas back and forth over the advantages of akmods versus kmods.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html

Upgrade from Fedora 10 to Rawhide (Fedora 11)

Following a report from Uwe Kiewel that a 

yum upgrade

had spewed all sorts of errors the supported methods for upgrades were re-stated[1] by Adam Williamson: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html
Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=105137"