From Fedora Project Wiki

< FWN‎ | Beats
 
(47 intermediate revisions by the same user not shown)
Line 2: Line 2:
== Developments ==
== Developments ==


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


Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== FLOSS Multimedia Codec Support ===
=== Would You Like to Write This Beat ? ===


Inspired by previous discussions on whether Fedora should distribute FLOSS content<ref>http://fedoraproject.org/wiki/FWN/Issue161#Electronic_Design_Automation_Content_Without_Tools_.3F</ref>  [[User:Mso|Martin Sourada]] tried<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00794.html</ref> to start a discussion about the poor support of FLOSS multimedia. Martin noted: "Out of the combinations of two FLOSS containers (matroska and ogg) and two FLOSS video codecs (dirac and theora) I know only one (ogg + theora) actually works in xine-lib (used by KDE4) which is pathetic." He asked for help in documenting the situation on a wiki page<ref>http://fedoraproject.org/wiki/User:Mso/Open_Multimedia</ref>.
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.


When [[BastienNocera|Bastien Nocera]] suggested that the most important thing was to file bugs Martin responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00826.html</ref> that this was what he was doing after first performing tests.
<references/>


An information packed sub-thread started<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00800.html</ref> by [[GregoryMaxwell|Gregory Maxwell]] expanded the scope of the tests and started a discussion with [[User:Rathann|Dominik Mierzejewski]] about the problem of <code>ffmpeg</code> providing sub-optimal implementations of unencumbered codecs. It seems that for reasons of efficiency <code>ffmpeg</code> re-invents the wheel from scratch instead of using and improving upstream implementations.  [[User:Kkofler|Kevin Kofler]] also rose<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00806.html</ref> to the implied challenge that <code>GStreamer</code> was preferable to <code>xine-lib</code>.
=== Is gNaughty a Hot Babe ? ===


<references/>
[[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.


=== Multiple Packages from One Source ? ===
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?"


A question about how to handle the situation where a single source could be compiled with alternate databases was posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00918.html</ref> by [[User:Moixs|Steven Moix]]. The <code>motion</code> video motion detector software can be compiled to use either <code>MySQL</code> or <code>Postgres</code>.  Steven explained that the problem was that "[...]you can't divide it into sub-packages, at the end it generates one big binary file [...]" and wondered should he just choose the database he preferred or propose two packages.
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.


[[ManuelWolfshant|Manuel Wolfshant]] expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00920.html</ref> what appeared to be the common wisdom: "personally I would compile twice, once enabling mysql and another time pgsql, and create 2 packages. each package would install a "motion-dbname" binary, and a symlink would allow access via the well known name "motion". Using alternatives would allow a switch between the two."
<references/>


Although it was admitted that [[DavidWoodhouse|David Woodhouse's]] suggestion<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00923.html</ref> to make the program use loadable plugins was the ideal [[TomLane|Tom Lane]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01091.html</ref> that was "[...] a bit above and beyond what a packager should do.  If he's also an upstream developer, then he should undertake that addition with his developer hat on; but it's *well* beyond the size of patch that a Fedora package should be carrying."
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


The ability to specify alternate requires (similar to those used in the .deb package format<ref>http://www.debian.org/doc/debian-policy/ch-relationships.html</ref>) was discussed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01097.html</ref> by [[RichardJones|Richard W.M. Jones]] and [[TomLane|Tom Lane]] and dismissed as impractical in this case anyway due to variations in SQL.
[[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?"
 
[[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/>


=== Take a Peek at the Fedora 11 Release Notes ===
=== Who Wants a Pony? ===


Fresh from his work on the <code>RHEL-5.3</code> Release Notes [[RyanLerch|Ryan Lerch]] apprised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00910.html</ref> the list of the latest changes to the <code>Fedora 11</code> Release Notes. Ryan sought early feedback and changes to documentation beats in order to give the community an early preview of the release notes.
[[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.
 
Initial feedback from [[User:Thl|Thorsten Leemhuis]] and [[User:Kkofler|Kevin Kofler]] and others indicated that the use of fixed-width instead of liquid layout was disliked by some people and loved<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00942.html</ref> by others.
 
Ryan also provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00911.html</ref> an rpm of this Release Notes mockup.


<references/>
<references/>


=== Heads Up: Noarch Subpackages Landing Soon ===
=== Firestarter Retired as Unportable to PolicyKit ===


[[User:Ffesti|Florian Festi]] warned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01012.html</ref> that the ability to produce noarch subpackages will soon be available in Fedora. This brings the benefit of being able to share these packages among different architectures thus reducing disk space and mirror bandwidth.  
[[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>.


Although <code>rpm-4.6</code> supports <code>noarch</code> fully there are still some fixes to make to <code>koji</code> before the Fedora buildsystem can cope with noarch subpackages. Florian suggested that those who wanted to could experiment in <code>mock</code> with <code>rpmdiff</code> to compare the results across different architectures. He assured readers that there were no plans to force packagers to use this feature and invited anyone interested in developing the use of noarch in future release to a discussion.
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/>


Florian later warned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01020.html</ref> that one potential negative outcome of using such sub-packages would be a proliferation of packages and consequent bloating of metadata which might affect <code>yum</code>.
=== Russian Fedora ? ===


[[User:Scop|VilleSkyttä]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01023.html</ref> that it would be wise to make sure that use of <code>BuildRequire: rpm-build >= 4.6.0</code> was enforced in order to ensure that earlier versions of <code>rpmbuild</code> did not produce <code>noarch</code> versions of the main package and other potential subpackages. Florian's response recognized<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01046.html</ref> the problem but deprecated the use of <code>BuildRequires</code> to such an extent. One possible alternative which he proposed was to have [[PanuMatilainen|Panu Matilainen]] "[...] backport a check that will make noarch packages (both regular and noarch) fail to build if they contain binaries [and ensure that this] additional check will be in place before koji will be updated[.]" This latter proposal stimulated a good deal of interest from [[RalfCorsepius|Ralf Corsepius]] and [[RichardJones|Richard W.M. Jones]] as they were both concerned with cross-architecture issues. The definition of a "binary" seemed to be one unclear point.
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.


In a later thread Florian updated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01105.html</ref> a list of packages which could be easily turned into noarch subpackages.
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]].


<references/>
<references/>


=== Mass Rebuild Coming Soon ===
=== Will FESCo Revisit Kmods ? ===
 
[[JesseKeating|Jesse Keating]] drew attention to "[...] a perfect storm brewing for Fedora 11" due to the need to rebuild with <code>GCC-4.4</code> (see FWN#161<ref>http://fedoraproject.org/wiki/FWN/Issue161#GCC:_Default_ISA_Flags_and_Glibc</ref>, the use of i586 as the default supported architecture (see FWN#162<ref>http://fedoraproject.org/wiki/FWN/LatestIssue#Fedora_11_Will_Support_i586_Instruction_Set</ref>) and the support of stronger hashes (last paragraph of FWN#107<ref>http://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation</ref>).


Apparently the time-constraints led to a desire to start the rebuild as soon as possible without giving maintainers an explicit window in which to do their own builds. Jesse preferred to give maintainers an ability to opt-out and sought suggestions on how this could be achieved.
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]].


Jesse suggested that interested parties should either reply to the thread and/or participate in the 2009-02-16 IRC meeting in #fedora-meeting at 1800UTC.  
[[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>.


<references/>
<references/>


=== New Tool Measures Ease of Cross-compiling to Windows ===
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===
 
[[RichardJones|Richard W.M. Jones]] announced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01055.html</ref> the availability of <code>CrossReport</code>, a tool to evaluate the ease with which applications can be ported to Windows using the <code>MinGW</code> libraries.


After some issue with platform dependency were reported by [[MichaelCronenworth|Michael Cronenworth]] were sorted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01074.html</ref> out it seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01076.html</ref> the tool is ready for use.
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"