From Fedora Project Wiki

< FWN‎ | Beats

(devel beat #144 only quickly edited, basic spellchecking, basic wiki markup. could probably use some love.)
(FWN #145 spell-checked, basic pass for naming correctness and correct use of code tags)
Line 1: Line 1:
{{Anchor|Developments}}
=== Default Deactivation of Services ===
== Developments ==


In this section the people, personalities and debates on the @fedora-devel
[[ChristophHoger|Christoph Höger]] initiated[1] this week's mammoth thread with a request to disable four services currently activated by default: <code>sendmail</code>, <code>ip6tables</code>, <code>isdn</code> and <code>setroubleshootd</code>. Christoph invited the list to "go on and punish me" after supplying some brief reasons for the deactivations.
mailing list are summarized.


Contributing Writer: [[OisinFeeley|Oisin Feeley]]
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02197.html


=== Removal of non-X Consoles (continued) ===
Discussion mostly centered on the <code>sendmail</code> problem with suggestions ranging from starting it asynchronously and late, as suggested[2] by [[AlanCox|Alan Cox]], to replacing it with one of the "send-only" MTAs such as <code>ssmtp</code>. Part of the interest over this seemed to be stimulated by the information posted[3] by [[ColinWalters|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 [[BillNottingham|Bill Nottingham]]. Some apparent legal threats posted by [[MatthewWoehlke|Matthew Woehlke]] led[5] [[SethVidal|Seth Vidal]] to point him to the nearest convenient exit. [[RalfErtzinger|Ralf Ertzinger]] noted[6] the deeply entrenched nature of <code>sendmail</code>: "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."


The furore over the future removal of text-mode consoles (see FWN#144 "Non-X System Consoles to be Removed"[1]) continued throughout the week. The original thread saw some support for the idea expressed[2] by [[NicolasMailhot|Nicolas Mailhot]] on the basis that "[...] non-X-console input is a mess [...] font support has fossilized, and support for modern high resolution screens is severely lacking [...]" Nicholas was especially concerned[3] with the maintenance burden imposed by the text-mode console "[...] as someone who is an upstream maintainer for my language of some of the bits the console use[s]."
[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02410.html


[1] https://fedoraproject.org/wiki/FWN/Issue143#Non-X.System.Consoles.to.be.Removed
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02203.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01341.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02308.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01347.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02384.html


Upon being pressed by [[DominikMierzejewski|Dominik Mierzejewski]] for evidence of a lack of proper maintenance Nicolas listed[4] a series of problems including the stagnation of the console layout database and the console font set. [[DmitryButskoy|Dmitry Butskoy]] begged[5] to separate the concepts of "console" and "serial tty" and also for the retention of the text-mode console. Dominik promised to try to find a colleague to shoulder the maintenance burden but Nicolas had already given up[6] in disgust. In response elsewhere to [[SethVidal|Seth Vidal's]] argument that the text console did no harm and should be left alone Nicholas expanded[7] on the maintenance costs of "all sorts of packaging rules designed to avoid hitting console limitations and problems" and bugs filed because of the confusion caused by two text stacks.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02505.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01373.html
The problem of lack of local delivery with the proposed replacements was brought up[7] by [[PatriceDumas|Patrice Dumas]]. This was seen as a stumbling block because <code>cron</code> needs it and led [[JesseKeating|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." [[MattMiller|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 [[ArjanvandeVen|Arjan van de Ven]] pointed[11] to aliases generation as the reason for <code>sendmail</code> being slow to start up.


[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01381.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02246.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01388.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02253.html


[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01396.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02349.html


[[LesMikesell|Les Mikesell]] got to the heart of the problem when he asked[8] "I think I'm confused by the term 'non X consoles'. Is that something different than the native text mode you see before X starts?" He also recommended using FreeNX/NX instead of using the console. Nicolas responded[9] that there were "[...]two different things. A VT to which you can attach an X session, a serial port, a remote SSH, mingetty... and the software stack used to display locally the VT text and collect user input." Nicolas saw the "low-level VT bit" as fundamentally sound but the "current console software stack" as "rotten." Les sought[10] further clarification of this distinction between "[...] the low level part that works in character mode and expects some hardware to supply and render the fonts [...]" and "[...] software other than X that renders custom fonts[.]"
[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02411.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01353.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02217.html


[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01354.html
The complaint about <code>setroubleshootd</code> was addressed[12] by [[SteveGrubb|Steve Grubb]]. He explained that he had intended it to be a plugin to <code>audispd</code> it but had ended up being implemented as a standalone daemon by another author.


[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01422.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02322.html


[[DenisLeroy|Denis Leroy]] wondered[11] if there was "[...] an X-based mingetty replacement actually exists ? Something that's proven to be sufficiently fail-safe (will work even with half-broken X configurations and such?)" and although Nicolas did not know of one he speculated[12] "[...] as soon as much of the hardware pocking is moved from xorg to the kernel and X can be run as a normal user "X-based mingetty replacement" will be just running a x term fullscreen in an autoconfigured X instance. Of course one could theoretically write a much lighter solution using only freetype (cairo, pango?) and an xkb-config parser." Denis's concern seemed to be that often a Ctrl+Alt+F1 to ''mingetty'' was the only way to kill hanging desktop applications. [[ColinWalters|Colin Walters]] suggested[13] making "[...] Ctrl-Alt-Backspace just break server grabs instead of killing the server (and of course fix the bugs in the apps that hang while holding a server grab)."
<code>ip6tables</code> was defended on two fronts. On the first [[DanielBerrange|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 [[GregoryMaxwell|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. :)" [[StephenSmoogen|Stephen John Smoogen]] also explained[15] that if there were no IPv6 firewall a <code>ping6 -I eth0 ff02::1</code> would enable an attacker to "walk the hosts with no firewalls." He suggested that completely disabling IPv6 would be preferable but might affect <code>IPsec</code> and related components.


[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01401.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02286.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01407.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02271.html


[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01366.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02206.html


There were multiple expressions of disapprobation often coupled with use cases. Some of these led [[ChrisSnook|Chris Snook]] to exclaim[14] "Unless I've missed something huge, virtual terminals aren't going away. What may or may not be going away is the x86 video BIOS text mode, to be replaced with a kernel framebuffer, which precludes the use of console fonts, which very few people ever mess with. The console itself will remain. Someone please correct me if I'm wrong." [[DaveAirlie|Dave Airlie] confirmed[15] this understanding and added "[...] vga text mode will not be enabled by default, you will need to pass nomodeset if you want to use vga text mode. Welcome to the 1990s." [[AlanCox|Alan Cox]] made[16] the correction that framebuffer console support fonts but that framebuffers did not work on all machines, screen reader technology and remote management cards.
No one seemed particularly concerned at the idea of disabling <code>isdn</code> by default as it explicitly requires further configuration to be useful.


[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01417.html
=== specspo and PackageKit ===


[15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01445.html
A quick query was posted[16] by [[RichardHughes|Richard Hughes]] asking whether <code>PackageKit</code> should dump its dependency on <code>specspo</code>[17]. The advantage would be a savings of 27Mb installed size and 6.9Mb download size. [[TimLauridsen|Tim Lauridsen]] was against a hard dependency and argued[18] that as <code>specspo</code> 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/msg01484.html
[16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02026.html


=== OpenVPN and resolv.conf ===
[17] "specspo" is the rpm package which contains all the portable object catalogues which provide translations for Fedora packages.


[[AhmedKamal|Ahmed Kamal]] asked[1] for help in scratching an itch and started a concise, meaty thread. His particular problem was that he wanted to overwrite /etc/resolv.conf with new DNS servers obtained over a vpn tunnel, this is apparently done automatically in "Windows".
[18] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02034.html
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01304.html
 
The suggestion to use NetworkManager was made by [[PaulWouters|Paul Wouters]] and [[DanWilliams|Dan Williams]] agreed[2] and added the explanation that it "[...] mediate[d] between services [including PPP, PPtP, DHCP, openvpn, and vpnc] that need to update your DNS information." The alternative is that each service needs to handle <code>/etc/resolv.conf</code> itself.


[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01313.html
An interesting discussion about alternate methods to provide translated package descriptions ensued when [[SethVidal|Seth Vidal]] suggested[19] that instead of using <code>specspo</code> "translating pkgs might best be served by translating the metadata in external files." In response to [[BillNottingham|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 <code>yum</code> downloading translations from a language-segmented repodata and inserting those translations into the local <code>rpmdb</code>. A further reason to find an alternative to <code>specspo</code> was advanced[22] by [[StepanKaspal|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'."
 
The idea of a default caching daemon was floated[3] by [[SimoSorce|Simo Sorce]]. As he envisioned it, the services/tools, such as OpenVPN, would "[...] tell the caching daemon which IP ranges and which domains their provided forwarders should be consulted for. All dynamic so that as soon as one daemon goes away, the caching DNS will notice and revert queries to the default DNS.} [[NilsPhilippsen|Nils Philippsen]] agreed[4] heartily and added that "[i]deally, it should be something which isn't restricted to class A/B/C like reverse DNS (seems to be), but which would route DNS requests based on arbitrary domain name or IP-range criteria to the desired name servers" and [[PaulHowarth|Paul Howarth]] provided[5] the further reason that changes to /etc/resolv.conf are often not picked up by processes. This latter point spawned a discussion on the demerits of the glibc stub resolver (which is too simplistic) and the consequent use of the deprecated <code>gethostbyname</code> in individual applications. [[DanWilliams|Dan Williams]] recommended using <code>lwresd</code> (a stripped-down, caching-only nameserver available to clients which use the BIND 9 lightweight resolver library) or for more complex setups a local caching nameserver. Although [[SimoSorce|Simo Sorce]] disagreed[6] with Dan that many applications were simply using <code>gethostbyname</code> he agreed that "[a] caching nameserver that can be instructed what to do when conditions change is what we really need."


[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01349.html
[19] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02058.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01485.html
[20] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02125.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01490.html
[21] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02164.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01632.html
[22] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02160.html


Ahmed asked[7] whether <code>dnsmasq</code> or other daemons were able to "[direct] name resolution to specific servers according to IP ranges and/or domain names, with the option of adding/removing servers on the fly?" and [[RichardJones|Richard W.M. Jones]][8] confirmed that this was indeed possible. [[AdamTkac|Adam Tkac]] suggested[9] that this could be done with <code>view</code> statements in <code>BIND</code> and the gauntlet of how to do this for CIDR and domain names was thrown down[10] by Nils. A detailed sub-thread followed which indicated what while possible it was not pretty.
[[BillNottingham|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."


[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01498.html
[23] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02165.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01500.html
=== Are Other Distros Controlling Fedora through PackageKit ? ===


[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01508.html
A thread initiated[24] by [[ThorstenLeemhuis|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 <code>PackageKit</code>[25] application installer defines and presents groupings of packages. <code>PackageKit</code> 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 <code>PackageKit</code> developers were not spending time helping to refine the <code>comps.xml</code> file which defines how packages are bundled during installation and is used by every other tool.


[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01523.html
[24] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01813.html


[[AdamTkac|Adam Tkac]] shared[11] the information that his TODO list includes the addition of <code>NetworkManager</code> support to <code>BIND</code> and [[SimoSorce|Simo Sorce]] explained [12] that <code>nscd</code> was not a solution for a local caching nameserver "[...] as not all type of queries can be fulfilled by the glibc interface. For example SRV/TXT records ... Also nscd is not smart enough to understand network condition and adapt it's behavior." Simo agreed that it would be nice if "[...] bind could consult different DNSs based 1) on the DNS name to be queried, and B) the reverse IP to be queried" so that on slow links only the necessary queries would be directed through the VPN.
[25] http://packagekit.org/pk-intro.html


[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01509.html
Thorsten asked a series of questions about the correct use of <code>comps.xml</code> and how it interacted with <code>anaconda</code>, <code>PackageKit</code> and <code>yum</code>. Thorsten was concerned that there appeared to be 1711 packages missing from <code>comps.xml</code> in order that "[...] people can find and select them right during install with anaconda. Do we care?"


[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01510.html
After some investigation with the latest <code>PackageKit</code>, which [[RahulSundaram|Rahul Sundaram]] pointed out[26] uses <code>comps.xml</code>, Thorsten deduced[27] in discussion with [[TimLauridsen|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." [[TimLauridsen|Tim Lauridsen]] explained[28] that <code>PackageKit</code> used the comps.xml groups as "meta-packages" but [[JamesAntill|James Antill]] disagreed[29] that they were similar.


=== Fedora 10 Feature Owner Request ===
[26] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01819.html


[[JohnPoelstra|John Poelstra]] requested[1] all those owning a Feature[2] to take some actions on their feature page so that the beta release notes and announcements are accurate. He provided a list of twenty one feature pages which "have not been updated since the Feature Freeze on 2008-09-11 and/or are not 100% complete."
[27] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01861.html


[[KevinKofler|Kevin Kofler]] was among those who had been watching the progress of OpenChange (see FWN#133 "Help Wanted: Samba4, Heimdahl, OpenChange"[3]) and noted[4] that due to the decision[5] of [[AndrewBartlett|Andrew Bartlett]] to orphan the feature it needed a new owner if Fedora 11 was to offer OpenChange.
[28] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01859.html


Another of the listed pages was that for the Echo icon theme and [[LuyaTsimbalanga|Luya Tshimbalanga]] asked if he should add a release note to the effect that <code>echo</code> was now the default. [[RahulSundaram|Rahul Sundaram]] confirmed that this would be helpful.
[29] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01889.html


The Eclipse-3.4 (Ganymede) page was updated[6] by [JeffJohnston|Jeff Johnston]].
[[AlexLancaster|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 [[ToshioKuratomi|Toshio Kuratomi]] had been thinking about using <code>PackageDB</code> to generate <code>comps.xml</code> for some time[31].


[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01471.html
[30] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01893.html


[2] http://fedoraproject.org/wiki/Features/Policy/Definitions
[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


[3] http://fedoraproject.org/wiki/FWN/Issue133#Help.Wanted:.Samba4.2C.Heimdahl.2C.OpenChange
In sustained discussion with [[KevinKofler|Kevin Kofler]] a defense of <code>PackageKit</code> was mounted[32] by [[RichardHughes|Richard Hughes]] using the argument that it was intended to be a compliment to <code>yum</code> 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.


[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01482.html
[32] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02015.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00522.html
[[JamesAntill|James Antill]] had done[33] some investigation of the difference between how PackageKit and <code>yum</code> 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."


[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01548.html
[33] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02008.html


=== system-autodeath Becomes Reality ===
The evolution of <code>comps.xml</code> to its current complexity was advanced[34] by [[NicolasMailhot|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."


[[SethVidal|Seth Vidal]] announced[1] that he had implemented his previously discussed (FWN#140 "System Autodeath"[2]) idea to automatically remove networking capabilities from machines which lacked system updates. The intent is to prevent non-maintained machines from being exploited.
[34] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02089.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01716.html
When it seemed that <code>PackageKit</code> 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 [[JesseKeating|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." [[MatthiasClasen|Matthias Clasen]] characterized[37] this as Jesse being more interested in confrontation than making things better but [[NicolasMailhot|Nicolas Mailhot]] also saw[38] the decisions being made about <code>PackageKit</code>'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.


[2] https://fedoraproject.org/wiki/FWN/Issue140#System.Autodeath
[35] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01957.html


Seth implemented the concept as a daily cronjob which tests a configured "death date" against the current time. For the week leading up to the "death date" log messages warn that on the specific date the default route will be deleted. He requested feedback and improvements.
[36] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01974.html


[[MattMiller|Matt Miller]] was content but suggested[3] beefing up the manpage with details of the consequences of removing the default route. Seth noted that he was happy to accept patches.
[37] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01976.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01779.html
[38] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02012.html


A fraught note was introduced when [[StephenWarren|Stephen Warren]] declared[4] that if this were a default then, in combination with the proposed textconsole removal (see this FWN#144 "Removal of non-X Consoles (continued)") and the modesetting changes[5], he was thinking about switching distros. [[RahulSundaram|Rahul Sundaram]] responded[6] that modesetting was going to be a feature of all distros soon and the conversation veered[7] into explaining that the replacement for <code>RHGB</code>, named "Plymouth" had a sane text-mode fallback for unsupported chipsets. As much of Stephen's angst was due to a perceived abandonment of those using non-Free drivers Rahul pointed out that the <code>nouveau</code> drivers might work. [[RichardHughes|Richard Hughes]] listed[8] 2-D and <code>xrandr</code> as supported with kernel modesetting coming soon due to [[Maarten Maathuis|Maarten Maathuis's]] work. He warned: "Don't even try 3D yet. It does work, but only if the moon is waxing, and your pet cat is called Oliver."
[39] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02022.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01782.html
The issue of binary packages (several of which can be produced from any single source package) was attacked when [[ToshioKuratomi|Toshio Kuratomi]] listed[40] <code>PackageDB</code>, <code>amber</code>, <code>koji</code>,<code>comps.xml</code>, <code>repoview</code> and <code>Fedora collection</code> as all "[...] doing a subset of the work in this area." He asked for some clarity as to the storage, interface and presentation layers. [[KevinFenzi|Kevin Fenzi]] agreed but added[41] <code>mash</code> as another player and suggested that perhaps all the developers of the respective systems could meet to hash out some agreed plan. [[JesseKeating|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."


[5] http://fedoraproject.org/wiki/FWN/Issue143#Graphics.Modesetting.Changes
[40] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01949.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01783.html
[41] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02182.html


[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01789.html
[42] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02185.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01802.html
=== /sbin and /bin Linked to /usr/lib ===


Back on the main topic of the thread Seth stated[9] that <code>system-autodeath</code> was not intended to be part of the default install: "This is just a nicety for sysadmins or local-respin maintainers who would like to put a dropdead date on their releases." In response to Stephen's recollection Seth also stated[10] this point clearly. A general disagreement with the idea of exposing such a feature was expressed[11] by [[JamesHubbard|James Hubbard]] on the basis that the user should be forced to change a config file to prevent against accidental installation errors.
[[SteveGrubb|Steve Grubb]] posted[43] the output from a utility which he had authored to check whether applications in the <code>/bin</code> and <code>/sbin</code> directories link against anything in the <code>/usr</code> directory. In the ensuing discussion [[BillCrawford|Bill Crawford]] suggested[44] that one of the listed applications, <code>/bin/rpm</code> 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" <code>initrd</code> would help for machines without optical drives.


[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01784.html
[43] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02315.html


[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01788.html
[44] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02458.html
 
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01850.html
 
=== Fedora Not "Free" Enough for GNU? ===
 
A long-running thread which was started[1] on 07-09-2008 by [[MichelSalim|Michel Salim]] continues to attracted some heated discussion over the fact that Fedora is not recognized as a 100% Free software distribution by GNU although a derivative named "BLAG" (see also FWN#139[2]) is recognized as FLOSS.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00428.html
 
[2] http://fedoraproject.org/wiki/FWN/Issue139#Small.Machine.SIG
 
The central stumbling block seemed[3] to be best stated by [[GregoryMaxwell|Gregory Maxwell]] as "[...] Fedora doesn't yet strip the binary firmware provided by the Linux kernel (and still provides some re-distributable binary firmware in other packages, the microcode package and alsa-firmware I think)." Gregory described the situation as unfortunate due to both the lack "[...] of acknowledgement it deserves, and the FSF is indirectly promoting Ubuntu, a distribution which is, as far as I can tell, a primary driving factor in new users using and depending on proprietary software." This latter being a reference to the recognition of gNewSense as FLOSS.
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00435.html
 
There had been previous very heated threads on this subject (during one of FWN's holidays) centered around the efforts of [[AlexandreOliva|Alexandre Oliva]] to produce a "kernel-libre" and the interaction of this project with other efforts and approaches within the kernel community. [[DavidWoodhouse|David Woodhouse]] added[4] the excellent news that "We are almost at the point where we can do a spin which remedies [the difficulties of stripping out the non-Free firmware]." He explained that soon a completely separate package instead of a sub-package of the normal kernel build will allow others to produce alternative packages of firmwares for which source code is available. [[TomCallaway|Tom Callaway]] was worried[5] that there was still firmware entangled in the kernel source code and noted the need for an audit. [[RahulSundaram|Rahul Sundaram]] supplied[6] a link to a Debian inventory of firmwares.
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01603.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01605.html
 
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01606.html
 
Other interesting points in the discussion touched on the rationales which have been often advanced for refusing to supply source to firmwares. These involve regulatory compliance (often for radio devices). [[AlanCox|Alan Cox]] was suspicious of such arguments based[7] on the history of examples such as ISDN code which "[...] was approved. You could change it but then it became unapproved and not permitted in some countries." He described this as a racket run by the phone companies which imploded once the need to ensure robustness became important (due to terrorist threats.) [[IgnacioVazquezAbrams|Ignacio Vazquez-Abrams]] listed[8] some of the other rationales.
 
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01745.html
 
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01737.html

Revision as of 17:57, 28 September 2008

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

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=52089"