Developments
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
The Possible Future of Comps ?
Seth Vidal reported[1] that one outcome of the recent FUDCon[2] had been an initiative to overhaul the comps.xml file. This file is part of the metadata used to define group membership of related packages in order to allow[3] yum or anaconda to aid in installation.
Seth described the intent to replace the fixed group definitions with metapackages created on-the-fly, based on examining and dependency-solving repository metadata, as "a fairly radical departure". Related changes will be the ability to define groups within groups and the addition of new metadata to allow tag cloud classification. Some of the anticipated benefits are the ability to find desired software more easily, the creation of more fine-grained groups and a more intuitive persistence of groups.
One apparent sticking point raised by Bill Nottingham was that the flattening of the package levels included the removal of "conditional" packages and "[...] a large portion of the language support is built around conditional packages." Seth argued[4] that removing conditional packages was something which was desirable whether or not this particular initiative took hold. This seemed like a problem especially for KDE but Bill prototyped[5] a yum plugin to solve the problem.
Some examples in which removing a metapackage would not remove dependencies installed to satisfy the metapackage were teased out[6][7] in conversations between Josh Boyer and Seth and Jesse Keating.
Florian Festi thought[8] that the list of problems to be solved should be expanded to include how multilib is handled, the proliferation of noarch subpackages and poor implementations of parts of the tool-chain. He also emphasized that with the "increasing number of languages supported and packages being properly translated we ship more and more language dependent content the users are not interested in. We are currently missing both a way to package these contents properly and a mechanism the control which should be actually installed."
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00733.html
[2] http://fedoraproject.org/wiki/FUDCon
[3] http://fedoraproject.org/wiki/PackageMaintainers/CompsXml#How_comps_is_used
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00748.html
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00882.html
[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00751.html
[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00777.html
[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00841.html
New GPG Signing Keys for Each Release
Jesse Keating asked[1] what value Fedora users perceived in the presence of the "[...] two gpg keys per release, one for rawhide/updates-testing and one for the final release and stable updates."
Todd Zullinger suggested[2] that eschewing the importation of the "updates-testing" key would ensure that "[...] no packages from updates-testing are installed on a box [.]" Casey Dahlin disliked[3] such a use of keys to categorize things.
Todd asked if each new release would come with a new key, similar to the way this was handled after the infrastructure intrusion. He balanced the sense of confidence given by keeping a key around for a "reasonably long time" versus the mitigation of "the lack of any way to revoke a key in the rpm db [.]" Jesse confirmed[4] "[...] yes, we plan to use new keys each release. We can use gpg web-"-trust thing and sign the new keys with the old keys and whatnot, does that actually help people?j
Douglas E. Warner and Steve Grubb worried[5] that the inability to revoke keys exposed machines to repository metadata attacks and Steve revealed[6] that the import of keys is "[...] one of the few security sensitive actions that is not put into the audit system."
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00999.html
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01001.html
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01020.html
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01003.html
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01036.html
[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01050.html
libssl.so.7 Going Through a Bumpy Patch
Tomas Mraz advised[1] that he was going to build a new OpenSSL in rawhide which would require a soname bump due to minor breakage of the ABI. As a transitional measure he intended to temporarily provide symlinks to the old soname so that most of the 288 affected packages should continue working until they were rebuilt. Jesse Keating expressed[2] disquiet with the timing as the large number of rebuilds would be "[...] likely to break buildroots, break anaconda composes, break installs, break users. This isn't the kind of crap we want to land in rawhide just before a freeze, and just before an effort to turn that freeze into something usable. PLEASE wait until after Alpha has been cut to do this." He seemed slightly mollified[3] by Tomas' use of compatibility symlinks and rpm provides.
When Benny Amorsen wondered why such breakage was occurring again with openssl Tomas explained[4] that the design "declar[ed] some important structures which have to be changed/extended with new functionality in the public headers. Unless they move these structures to private headers this situation is going to happen again." Christopher Aillon joked[5] that it was happening again because Benny had not ported his applications to use NSS(see FWN#107[6]).
Later Horst von Brand reported[7] widespread problems with many packages which seemed to fail. RalfErtzinger explained[8] that "[t]he problem is that the openssl package was supposed to contain symlinks for libssl.so.7 and libcrypto.so.7, and rpm -ql says that the package does contain them, but they are, in fact, missing from the filesystem."
Tomas Mraz scrambled[9][10] to sort out the problem by trying to run ldconfig in the %post of the openssl package. Kevin Kofler suggested[11] a possible cause.
Jesse Keating fretted[12] that all of this was exactly what he did not want just before next week's alpha freeze[13].
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00758.html
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00761.html
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00764.html
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00880.html
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00977.html
[6] https://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation
[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00941.html
[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00942.html
[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00943.html
[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00946.html
[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01051.html
[12] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01000.html
[13] https://fedoraproject.org/wiki/Releases/11/Schedule
MinGW Package Reviews Requested
Richard W.M. Jones noted[1] that the rapid development cycle[2] meant that Fedora 11 was already approaching (2009-01-20) alpha-freeze and asked for package reviews of the outstanding parts of the MinGW Windows cross-compiler feature[3]. He offered to trade reviews with interested parties and provided links to outstanding reviews.
There is apparently no question that the feature, which will allow generation of Windows targets on Fedora, will slip from Fedora 11.
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00793.html
[2] https://fedoraproject.org/wiki/Releases/11/Schedule
[3] https://fedoraproject.org/wiki/Features/Windows_cross_compiler
MySQL 5.1 Coming to Rawhide After Alpha-Freeze
A heads-up was posted[1] by Tom Lane to advise that mysql-5.1.30 would be pushed into rawhide immediately after the alpha freeze. He warned: "This involves an ABI break: libmysqlclient.so has increased its major version number from 15 to 16 [...]" and provided a list of affected packages along with the offer to launch rebuilds for anyone who wished.
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00721.html
Spins SIG Controversy
A vigorous disagreement erupted when Jeroen van Meeuwen announced[1] that the Spins SIG[2] would henceforth be having meetings every two weeks (Jeroen later rescheduled[3] the meeting to Mondays at 17:00 UTC) and that the first meeting would be to finalize a new process arrived at during the last FUDCon.
Rahul Sundaram contended[4] that "[s]uch decisions shouldn't be taken at FUDCon because it automatically excludes people who cannot be present at the event. You should use the events only to discuss the issues and make the decisions over mailing lists or irc where others can participate as well." A long thread mostly involving just Rahul, Jeroen and Josh Boyer resulted.
In response to Rahul's point that the new process was onerous as it mandated a weekly compose and report JoshBoyer seemed[5] to be of the opinion that this was a good thing. BillNottingham added[6]: "It's not really adding anything to the amount of work that needs to be done, in total. It's just shifting around who it gets done by and when."
Some weight was given to Rahul's argument that the method of arriving at the new process was a problem when Jeroen posted[7] that no minutes had been kept of the meeting and pointed to a "5-minute after best-recollection of what happened" summary on the wiki[8] as a source of information.
JesseKeating argued[9] that FUDCon was a useful, "high-bandwidth" means of having discussions and that public email was too slow to make decisions compared to IRC, IM, phone and face-to-face meetings. Subsequently he added that the result of the FUDCon discussions was a proposal and not a decision and suggested that unless the skeleton process was approved quickly then there might be no spins for Fedora 11. Rahul responded[10] that the original post had been a simple declaration which did not suggest it was merely a proposal. Rahul added[11] that there was a need to clarify the process in order to avoid the confusion of the past.
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00695.html
[2] http://fedoraproject.org/wiki/SIGs/Spins
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00782.html
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00789.html
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00811.html
[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00826.html
[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00838.html
[8] http://fedoraproject.org/wiki/SIGs/Spins_NewProcess
[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00864.html
[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00872.html
[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00874.html