From Fedora Project Wiki

< FWN‎ | Beats

m (fas name Gianluca Sforna)
Line 10: Line 10:
 
A discussion over the possible ways to upgrade from Fedora 10 to Fedora 11 was started<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01145.html</ref> by [[GerryReno|Gerry Reno]] when he asked why <code>preupgrade</code><ref>http://fedoraproject.org/wiki/PreUpgrade</ref> from <code>Fedora 10</code> only presented <code>Rawhide</code> as an option and not <code>Fedora 11 Alpha</code>.
 
A discussion over the possible ways to upgrade from Fedora 10 to Fedora 11 was started<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01145.html</ref> by [[GerryReno|Gerry Reno]] when he asked why <code>preupgrade</code><ref>http://fedoraproject.org/wiki/PreUpgrade</ref> from <code>Fedora 10</code> only presented <code>Rawhide</code> as an option and not <code>Fedora 11 Alpha</code>.
  
A quick answer posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01147.html</ref> by GianlucaSforna mentioned the technical difficulties of tracking the versions of packages included in the alpha release. [[User:Pfrields|Paul W. Frields]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01168.html</ref> concerned that anyone trying such an upgrade made sure to update <code>rpm</code> before upgrading.  This latter point spawned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01185.html</ref> a longish thread in which the possibility of making <code>YUM</code> take care of checking to see whether a newer version of itself or <code>rpm</code> is available.
+
A quick answer posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01147.html</ref> by [[User:Giallu|Gianluca Sforna]] mentioned the technical difficulties of tracking the versions of packages included in the alpha release. [[User:Pfrields|Paul W. Frields]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01168.html</ref> concerned that anyone trying such an upgrade made sure to update <code>rpm</code> before upgrading.  This latter point spawned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01185.html</ref> a longish thread in which the possibility of making <code>YUM</code> take care of checking to see whether a newer version of itself or <code>rpm</code> is available.
  
 
[[User: Wwoods|Will Woods]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01254.html</ref> that running <code>preupgrade</code> isntead of doing a <code>`yum upgrade'</code> avoided all that confusion.
 
[[User: Wwoods|Will Woods]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01254.html</ref> that running <code>preupgrade</code> isntead of doing a <code>`yum upgrade'</code> avoided all that confusion.

Revision as of 15:39, 23 March 2009

Developments

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

Contributing Writer: Oisin Feeley

Auto Upgrading YUM Not Worth It

A discussion over the possible ways to upgrade from Fedora 10 to Fedora 11 was started[1] by Gerry Reno when he asked why preupgrade[2] from Fedora 10 only presented Rawhide as an option and not Fedora 11 Alpha.

A quick answer posted[3] by Gianluca Sforna mentioned the technical difficulties of tracking the versions of packages included in the alpha release. Paul W. Frields was[4] concerned that anyone trying such an upgrade made sure to update rpm before upgrading. This latter point spawned[5] a longish thread in which the possibility of making YUM take care of checking to see whether a newer version of itself or rpm is available.

Will Woods suggested[6] that running preupgrade isntead of doing a `yum upgrade' avoided all that confusion.

How to Update from Fedora 10 to Rawhide

When "nodata" reported[1] that an attempt to update rpm resulted in errors and preupgrade also failed he concluded[2] that the instructions[3] on the wiki were flawed.

Seth Vidal and Jesse Keating were[4] sure that "nodata" was not using the correct procedure which they stated as a two stage process with the first step being a:

yum update rpm

with the Fedora 10 repository enabled and then to enable the Rawhide repository and do a general:

yum update

Unfortunately this seemed[5] to not work for "nodata" and Michael A. Young's suggestion[6] that a "[...] temporary issue with F10 having a more recent version of audit-libs than rawhide [...]" seemed like a promising lead. "Nodata" resolved[7] problem by using the rescue CD to do a "rpm -e --nodeps" and then "rpm --rebuilddb".

Fedora 11 Beta Slips by One Week

Jesse Keating announced[1] that Release Engineering, QA and maintainers had agreed that the beta release of Fedora 11 would slip by seven days due to several issues mostly related to the rewrite of anaconda storage.

Finding the Source

A request was posted[1] for help in finding the Fedora kernel sources by Joe Ovanesian. A quick pointer was given[2] by Tom Diehl:

# yum install yum-utils

# yumdownloader --source package_name

Eric Sandeen wondered[3] if it might be better to use the upstream repositories and Joe explained[4] that his objective was to build a new kernel from source and use KGDB[5] to gain familiarity with the source. Todd Zullinger pointed[6] to a goldmine of information on the topic on the wiki[7].

Fedorahosted Releases

Jon Stanley posted[1] a quick note to say that he had made it easier to specify the upstream source URL in specfiles due to a change in fedorahosted.org

How to Open ACLs and Find Non-responsive Maintainers

A couple of related threads dealt with the need to deal with a package which lay dormant apparently due to maintainer inactivity.

Manuel Wolfshant had inquired[1] earlier in the week about the allowing the provenpackagers to fix the gdal package. Jon Stanley promised[2] to re-add a ticket dealing with the issue to an upcoming FESCo meeting.

In a separate thread the latest Rawhide Report[3] led Kevin Kofler to ask[4] for an opening of the ACLs on gdal[5] so that it could be fixed for multiple dependent packages. When Jesse Keating asked[6] Alex Lancaster if he started the non-responsive maintainer process the answer appeared[7] to be that it was Jesse himself. In an aside MilosJakubicek provided[8] links to the current process. Alex seemed[9] to demonstrate clearly that the maintainer was inactive.