Developments
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Default Deactivation of Services
Christoph Höger initiated[1] this week's mammoth thread with a request to disable four services currently activated by default: sendmail, ip6tables, isdn and setroubleshootd. Christoph invited the list to "go on and punish me" after supplying some brief reasons for the deactivations.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02197.html
Discussion mostly centered on the sendmail problem with suggestions ranging from starting it asynchronously and late, as suggested[2] by Alan Cox, to replacing it with one of the "send-only" MTAs such as ssmtp. Part of the interest over this seemed to be stimulated by the information posted[3] by Colin Walters that the "[...] desktop image no longer installs sendmail by default." This led to a need to distinguish between the desktop LiveCD and regular installs, as was done[4] by Bill Nottingham. Some apparent legal threats posted by Matthew Woehlke led[5] Seth Vidal to point him to the nearest convenient exit. Ralf Ertzinger noted[6] the deeply entrenched nature of sendmail: "Unfortunately, sendmail isn't just a program, it's an API. Calling /usr/lib/sendmail has been the way to get mail out (wherever out is) in UNIX for, well, as long as sendmail exists, which is quite some time."
[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02410.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02203.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02308.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02384.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02505.html
The problem of lack of local delivery with the proposed replacements was brought up[7] by Patrice Dumas. This was seen as a stumbling block because cron needs it and led Jesse Keating to argue[8]: "[W]e shouldn't be using local delivery for this stuff. Instead we should ask in firstboot where you'd want the mail delivered to." Matt Miller replied[9] with a link to a bugzilla entry in which he had proposed just such a thing in 2004. Other aspects of the problem of disentangling potentially important log data from the mail delivery mechanism were touched[10] upon in other parts of the thread. Deep in the thread Arjan van de Ven pointed[11] to aliases generation as the reason for sendmail being slow to start up.
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02246.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02253.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02349.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02411.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02217.html
The complaint about setroubleshootd was addressed[12] by Steve Grubb. He explained that he had intended it to be a plugin to audispd it but had ended up being implemented as a standalone daemon by another author.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02322.html
ip6tables was defended on two fronts. On the first Daniel P. Berrange explained[13] how accessible IPv6 was and how likely it was that all machines on a network could automatically acquiring IPv6 addresses. Typical of the reaction on the other front Gregory Maxwell was startled[14] at the idea of being exposed without firewalling upon plugging into an IPv6 enabled network. He added the statistic that "About 4% of the web browsers hitting English language Wikipedia are IPv6 enabled. IPv6 enabled web clients may even become more numerous than Linux desktops this year, almost certainly by next year, so be careful what you call rare. :)" Stephen John Smoogen also explained[15] that if there were no IPv6 firewall a ping6 -I eth0 ff02::1 would enable an attacker to "walk the hosts with no firewalls." He suggested that completely disabling IPv6 would be preferable but might affect IPsec and related components.
[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02286.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02271.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02206.html
No one seemed particularly concerned at the idea of disabling isdn by default as it explicitly requires further configuration to be useful.
specspo and PackageKit
A quick query was posted[16] by Richard Hughes asking whether PackageKit should dump its dependency on specspo[17]. The advantage would be a savings of 27Mb installed size and 6.9Mb download size. Tim Lauridsen was against a hard dependency and argued[18] that as specspo was part of the @base group it would be installed by default on a normal desktop and could then be used, whereas on the LiveCD its absence was desired due to the space constraints.
[16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02026.html
[17] "specspo" is the rpm package which contains all the portable object catalogues which provide translations for Fedora packages.
[18] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02034.html
An interesting discussion about alternate methods to provide translated package descriptions ensued when Seth Vidal suggested[19] that instead of using specspo "translating pkgs might best be served by translating the metadata in external files." In response to Bill Nottingham's skepticism that this was just moving bloat to a new location Seth explained[20] that it would allow only the data specific to the requested language to be fetched. In a further explanation he provided[21] an overview of the ideal mechanism which would allow translations only for the language in use to be installed. This involved yum downloading translations from a language-segmented repodata and inserting those translations into the local rpmdb. A further reason to find an alternative to specspo was advanced[22] by Stepan Kaspal when he drew attention to its lack of friendliness to third-party repositories: "the specspo solution is not extensible at all; if you add a third part repository, the messages just are not there. And the repository cannot install another catalogue, rpm uses just 'the catalogue'."
[19] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02058.html
[20] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02125.html
[21] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02164.html
[22] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02160.html
Bill Nottingham's objections seemed[23] to involve both the resource intensiveness of doing this during the composition of the repodata and also that "[...] this is all stuff that exists."
[23] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02165.html
Are Other Distros Controlling Fedora through PackageKit ?
A thread initiated[24] by Thorsten Leemhuis explored some details on how information on packages is created and stored at the distribution level and the challenges this presents both to independent repositories and to tools which wish to use this data. One heated aspect of this discussion concerned the manner in which the PackageKit[25] application installer defines and presents groupings of packages. PackageKit is designed to be a distribution-independent tool and it appeared to some in the discussion that its direction was inimical to the best release-engineering practices of the Fedora Project. The central issue appeared to be that PackageKit developers were not spending time helping to refine the comps.xml file which defines how packages are bundled during installation and is used by every other tool.
[24] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01813.html
[25] http://packagekit.org/pk-intro.html
Thorsten asked a series of questions about the correct use of comps.xml and how it interacted with anaconda, PackageKit and yum. Thorsten was concerned that there appeared to be 1711 packages missing from comps.xml in order that "[...] people can find and select them right during install with anaconda. Do we care?"
After some investigation with the latest PackageKit, which Rahul Sundaram pointed out[26] uses comps.xml, Thorsten deduced[27] in discussion with Tim Lauridsen that "[...] adding packages to a group in comps.xml as '<packagereq type="optional">' is only worth the trouble if you want to make the package selectable in anaconda, as that information is not used by pk-application." Tim Lauridsen explained[28] that PackageKit used the comps.xml groups as "meta-packages" but James Antill disagreed[29] that they were similar.
[26] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01819.html
[27] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01861.html
[28] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01859.html
[29] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01889.html
Alex Lancaster agreed[30] with Thorsten's concern that many packagers were not using comps.xml and posted a link that showed that both he and Toshio Kuratomi had been thinking about using PackageDB to generate comps.xml for some time[31].
[30] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01893.html
[31] See also http://fedoraproject.org/wiki/FWN/Issue136#Application.Installer..22Amber.22.Provides.Browser.Interface.to.Packages and http://fedoraproject.org/wiki/FWN/Issue82#Presto.Server.Back.Up...Interesting..25doc.Behaviour..Presto.Now.in.Extras.21
In sustained discussion with Kevin Kofler a defense of PackageKit was mounted[32] by Richard Hughes using the argument that it was intended to be a compliment to yum rather than a replacement. Its intent is to occupy a very narrow niche for the specific type of user identified by "profiles" produced by the PackageKit developers.
[32] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02015.html
James Antill had done[33] some investigation of the difference between how PackageKit and yum presented groups of packages and was not impressed: "In short it's arbitrarily different, hardcoded and just plain wrong. But hey, you've done "substantial user research" while we're just lowly developers, so feel free to keep ignoring us."
[33] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02008.html
The evolution of comps.xml to its current complexity was advanced[34] by Nicolas Mailhot as the result of multiple constraints of engineering, maintenance and legality, he argued that "[i]t's always easy to present one-shot specialized solutions. The difficulty is scaling because separate maintenance of specialized overlapping package collections is not efficient). When you refuse to look at scaling problems you're missing the core of the problem."
[34] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02089.html
When it seemed that PackageKit was being designed[35] to take the needs of other distributions into account and that this might have a negative effect on Fedora there was a great deal of disapprobation expressed[36] by Jesse Keating: "If I'd known that upstream was actively looking to destroy our package classifications, rather than actually work with us to clean them up a bit maybe I would have joined the conversation. A heads up might have been in order. I fear that any conversation now will just be too little too late." Matthias Clasen characterized[37] this as Jesse being more interested in confrontation than making things better but Nicolas Mailhot also saw[38] the decisions being made about PackageKit's design as "non-representative" of developers focused on Fedora. Interestingly he tied this in with an observation on "[...] desktop team mislike for the common distro communication channel [.]" A slight rapprochement seemed[39] to be in effect towards the end of the thread as tempers cooled.
[35] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01957.html
[36] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01974.html
[37] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01976.html
[38] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02012.html
[39] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02022.html
The issue of binary packages (several of which can be produced from any single source package) was attacked when Toshio Kuratomi listed[40] PackageDB, amber, koji,comps.xml, repoview and Fedora collection as all "[...] doing a subset of the work in this area." He asked for some clarity as to the storage, interface and presentation layers. Kevin Fenzi agreed but added[41] mash as another player and suggested that perhaps all the developers of the respective systems could meet to hash out some agreed plan. Jesse Keating confirmed[42] Kevin's description and elaborated: "it's mash that pulls comps out of cvs and 'makes' it and uses it when generating repodata. Mash is used during rawhide production and during update repo generation. When we make releases, that uses pungi which consumes the comps data that mash generated and merges in data from any other repo pungi is configured to use. Then pungi calls repoview to create data based on that merged comps."
[40] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01949.html
[41] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02182.html
[42] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02185.html
/sbin and /bin Linked to /usr/lib
Steve Grubb posted[43] the output from a utility which he had authored to check whether applications in the /bin and /sbin directories link against anything in the /usr directory. In the ensuing discussion Bill Crawford suggested[44] that one of the listed applications, /bin/rpm was useful in its present location because of the "[...](admittedly quite odd situations) where you need to, say, reinstall grub or a kernel because you broke something[.]" He added that a "rescue" initrd would help for machines without optical drives.
[43] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02315.html
[44] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02458.html