FWN/Beats/Developments

Developments

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

Contributing Writer: Oisin Feeley

Splitting Up R

Tom Callaway alerted[1] the list that he intended to merge the R-devel package with the base R[2] package. Tom's motivation was that many complaints had been received from users who attempted to install extensions from the external CRAN[3] repository using R's built-in package system. "This doesn't work unless you have R-devel installed. The average R user is a professor or a student, and neither of them are going to necessarily possess the necessary Linux/Fedora knowledge to be able to understand why this doesn't work like the R documentation says it should." Tom recognized that this was a violation of the Fedora Packaging Guidelines[4] and that he was "[...] not entirely sure if I need FESCo or FPC approval to take this action, if so, this is my notice of requesting it. ;)"

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02240.html

[2] R is an interpreted language based upon S and Scheme intended to be used for statistical computation: http://www.r-project.org/

[3] http://cran.r-project.org/

[4] http://fedoraproject.org/wiki/Packaging/Guidelines

Enrico Scholz suggested[5] instead: "[...] add it to comps.xml [or] move 'R' to Rcore, and add 'R' which depends on 'R-core' + 'R-devel"' which have the major advantage of not missing all of R-devel's dependencies. Tom accepted[6] these points because "[...] the suggested R/R-core/R-devel split instead [would allow users] to get everything with yum install R, it would meet the guidelines, and minimal installs with R can simply have R-core."

[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02249.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02251.html

James Antill agreed that the general model of "foo-core + additions" was maintained by such a split but asked[7] "[...] why don't we just package more of the R modules so CRAN usage isn't a requirement?" José Matos answered[8] that there were far too many R modules "[...] more than 1500 modules (the have been growing at an exponential rate in the last years). So while we would like to see more R packages in Fedora in are not even near to have a reasonable subset of R packaged." James worried[9] that "[...] you could use that argument a lot (there are probably still more unpackaged libc using things than packaged)." James showed that there were many more unpackaged users of libc than packaged using:

repoquery -whatrequires '*-devel' | \
  fgrep -v - '-devel-' | \
  fgrep -v - '-static-'

[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02267.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02272.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02274.html

The availability of a tool named R2spec to convert R package formats to rpm packages was mentioned[10] by Matthew Salzman. Later threads which appeared in part only on @fedora-r-devel investigated the problem of languages implementing their own packaging systems. José Matos played[11] Devil's Advocate with the remark that "[...] each language is building its own repository and packaging system in a sense we have lots of equivalents of (yum+rpm) for each language (perl, php, python, R, tex, ...) [but] for the system to be really useful it must use the least possible denominator (read the dumbest wins- pun intended ;-) )." José suggested that R2spec could also be tweaked to discover dependencies and include them in its generated spec files. It appeared[12] that Pierre-Yves had a "[...] small script to update the spec file when there is a new release of an already package R-library. This might be something that I should develop maybe a bit more now (especially since Bioconductor[12a] 2.3 has been released with R 2.8.0)"

[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02288.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02301.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02306.html

[12a] Modules primarily for bioinformatics and genomics.

Flinging Poo at libtool-2.2

A discussion on the future of libtool in Fedora is worth reporting although it is slightly older. Orion Poplawski wondered[1] whether it was the correct time to integrate libtool-2.2.X into Fedora 11. Benjamin Kosnik wanted[2] it available in Fedora before GCC was bumped to gcc-4.4.x as that will depend on libtool-2.2.6.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00467.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00516.html

A possible need for FESCo approval was expressed[3] by Karsten Hopp as he was worried that "[...] it breaks up to 300 packages according to my mass rebuilds. I'm going to prepare a Wiki page with details about that." That prompted the first of several queries about the purpose and suitability of libtool. David Woodhouse asked[4] "[i]sn't the whole point of libtool that it should make things _easier_, not break huge swathes of packages whenever we change it? How about we fix those 300 packages by making them _not_ use libtool, rather than making them use the latest version?" Toshio Kuratomi thought[5] that "If the state of the art has advanced and there's a tool that can replace libtool so a developer can say `I want a shared library' and the tool builds it on all platforms then we could look into getting upstreams to switch but simply getting rid of libtool in favour of handcoding Makefiles to build shared libraries is a step in the wrong direction."

[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00479.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00730.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00737.html

AdamJackson offered[6] that gcc was available on Solaris, Windows, *BSD and OSX with the conclusion "[m]st of the complexity in libtool (and autotools in general) is to support systems that simply are not worth supporting and that practically speaking don't exist anymore. I'm being slightly flip in saying 'gcc -shared' but really not by much. Honestly for any fringe platform the correct thing to do is port gcc/binutils/gmake first." There were many disagreements on this point and Sam Varshavchik posted[7] a convincing potted summary of them: "There's much more to libtool then just building shared libraries. If you remove everything from libtool that supports ancient platforms, you'll still have quite a bit left. For example, libtool builds both shared and static libraries in parallel. That, alone, saves you from dealing with a massive hairball in your makefiles. Ask anyone who works on a large, complicated app, that links with its own shared libraries. The option to easily build a statically-linked version is quite invaluable, for debugging purposes."

[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00744.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00791.html

The practical experience of the MinGW project related[8] by DanielBerrange was also that gcc -shared was insuOEcient i[...] if you're trying to build for windows. The mingw32 work has only been made viable because libtool has basically taken care of the horrible shared library build process required by Windows.j Further details were supplied[9] at Adam's request and KevinKoAEer confirmed[10] that producing a DLL involved several complications.

[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00743.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00755.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00780.html

Discussion of alternatives veered[11] towards CMake. Braden McDaniel was unconvinced[12] that this was a realistic suggestion for replacing libtool in approximately three hundred upstream projects. Kevin Kofler took[13] a detailed look at the problem and argued that attempting to "[...] convince the automake developers to use something other than libtool is pointless, because automake should also go away, it's at least as obsolete, buggy, unable to maintain backwards compatibility, annoying, a massive time waster at build time and a major PITA for developers to code with as libtool is. The whole autotools stack sucks. It always did, we just didn't have anything better. We now do, so why are people still using autotools?" His critique seemed convincing and he later added[14] that "CMake is used by all of KDE 4 [...]" and in an exchange with Richard W. M. Jones explained[15] that Gnulib was also not a good replacement for autotools: "[...] a "library" which works by copying itself into the source code of the project is a horribly broken concept."

[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00780.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00775.html

[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00799.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01017.html

[15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01142.html

LennartPoettering and RalfCorsepius were[16] suspicious of the attempt to replace autotools with CMake. Ralf argued that "Cmake is imake in new clothes and suffers from the same design flaws as imake did. It's only the limited set of requirements being used by the limited set of use cases it's proponents apply which lets them think 'cmake is better'." StephenSmoogen saw[17] a need to halt the conversation when he examined it from a human neuropsychology viewpoint: "So basically this conversation is a 'dead' conversation. People have their hairs on their necks up, [enough] testosterone pumping to put [out] 3 or 4 beards in a day, and are [on] to the flinging poo part. At this point, there is no way either side is going to say that Cmake is better at this, or Autotools is better than that. Wait a week, and see if one can bridge the gap with some diplomatic discourse[.]"

[16] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00954.html

[17] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01023.html

Later a new thread was started[18] by Braden McDaniel to recommend that autoreconf should be explicitly forbidden to be run by rpm packages. He explained that he saw the problems caused by running autoreconf or libtoolize as "[b]y running autoreconf, the RPM build becomes exposed to different versions of autoconf, automake, and libtool than were used by the upstream developer to create the upstream source package. Newer versions of these tools have the potential to introduce incompatibilities, breaking the RPM build. Rather than patching configure.[ac,in] and Makefile.am, a more resilient approach is to patch the configure script and Makefile.in files."TillMaas added[19] a link to a wiki draft on the subject and suggested that "[...] one should run autoreconf locally and create a patch from this, that is then used within the spec." The conversation veered[20] into sharp disagreement as to whether autotool generated files should be treated similarly to "binary JARs (for which the packaging guidelines mandate that they have to be removed and rebuilt from source)" or this should be avoided in order to avoid "potential breakage". This issue seems destined to generate further disagreement.

[18] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00866.html

[19] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00869.html

[20] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00970.html

Livna Migration to RPM Fusion

Several of the third-party repositories external to the Fedora Project agreed some time ago to merge into a single new entity named "RPM Fusion"[1]. The current partners include Dribble, Freshrpms and Livna. Thorsten Leemhuis reported[2] that "[...] nearly all of livna's packages have been imported and build for RPM Fusion, but a few are still missing. So you should leave livna repos enabled for now if you want everything [.]" Thorsten explained the migration process in this post with the important details that "[...] all users that installed livna properly (e.g. by installing the livna-release package) and enabled the testing repos will now get RPM Fusion enabled automatically."

[1] http://rpmfusion.org

[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02367.html

A suggestion was made[3] by Nicolas Mailhot to either use the "modern proxyfriendly createrepo" or else "define http.caching=packages" in the yum repo files.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02368.html

Users who currently have the Livna repository enabled can transition to the new RPM Fusion repository by:

yum install rpmfusion-free-release rpmfusion-nonfree-release

Sbin Sanity Stays

The latest FESCo meeting[1] logs record that the decision to add /sbin to each users PATH variable (see FWN#146[2]) will be kept until a working alternative for both non-root and root users is available. The brief deliberations indicate that FESCo members tended to manually add /sbin to their own paths and distilled the objections to the sole point of "".

Thorsten Leemhuis was dismayed[3] and agreed with Ville Skyttä that the change would4 result in many confused users. Thorsten wished to "[...] help Ville and Matthew making a real solution, where sbin stays "root commands" only, and where package that are right now get into he search path for ordinary users (either with symlinks or by moving the binaries). But it's IMHO best for everyone if we do that for F11. Come on, we had /sbin not in the path for more then how many years, so what is one half year more (especially as everyone that dislikes it is used to enable it already)?"

Jon Masters disagreed[5] on the basis that any script should be using an explicit and absolute binary location anyway: "If you're writing scripts and not explicitly calling out the binary location, then it's not surprising if your scripts break later. I know it's nice to always assume a particular PATH, but it's not good practice any more than including or not including sbin in the PATH to begin with." He also cautioned that most other distributions had made this change a long time ago and that "[...] everyone else is already laughing that Fedora didn't do this, so really it doesn't need to wait for yet another 1.5 years to get done :)"

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02273.html

[2] http://fedoraproject.org/wiki/FWN/Issue146#PATH:.2Fsbin.Tab.Confusion

[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02294.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02180.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02296.html

Packaging Webmin: Should it go in /opt ?

Andy Theuninck asked[1] for some help in "[...] trying to put a package together for webmin. It wants to install to libexec, but if I do that rpmlint (rightly) complains that there are non-executable text files. Perl files & HTML files are intermixed and separating them out would be a patching nightmare [...] as I read FHS /opt would be the most appropriate place [but] if I try to use /opt/webmin [then] rpmlint pitches a fit about using /opt."

Toshio Kuratomi quoted[2] the FHS[3:] "The FHS says: /opt is reserved for the installation of add-on application software packages. Anything packaged by Fedora is part of the system packaging rather than an addon so we stay out of /opt." He also suggested that separating the different files types and getting webmin's upstream[4] to accept patches to do this was a preferred path in the Fedora Project. Failing this it was possible to separate the files and symlink them to the upstream-enforced layout. Another useful link[5] to the Fedora Project's web application packaging guidelines in Toshio's post indicated that non-executable files might best be put into /usr/share. Andy seemed[6] to like the idea of "[m]oving as much as possible over to /usr/share and symlinking against the files that are actually needed[...]" as this would allow upstream to continue to support many OSes by the simple expedient of "sticking everything into a single directory."

Nicolas Mailhot disparaged[7] the use of /opt as "[...] he right place to dump messes and is good enough for ISVs with no ambitions but Fedora does not package messes [.]" Casey Dahlin cautioned[8] Nicolas "Easy, he's here because he wants to do the right thing, and he's not upstream, so there's no reason to clueby4 him just yet" and went on to suggest a similar path to that above: "You might do what apache does and simply place the files where they go, then symlink them to a conf directory in /etc . You'd be doing it on a much larger scale than apache, but until you get upstream to suck less, you at least have a precedent for it (though doing it for apache hasn't particularly encouraged them to change their goofy-as-hell recommended file layout)."

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02289.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02291.html

[3] Filesystem Hierarchy Standard: http://www.pathname.com/fhs/

[4] http://www.webmin.com/

[5] http://fedoraproject.org/wiki/Packaging/Guidelines#Web.Applications

[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02327.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02297.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02300.html