From Fedora Project Wiki

m (removed category)
m (add the I left Fedora)
Line 1: Line 1:
= Patrice Dumas =
= Patrice Dumas =


I have left Fedora, but I am still involved in EPEL.
I have left Fedora, in Dec 2008, but I am still involved in EPEL.


I maintain science packages, chm (Compiled Help Modules) related packages, perl modules, gnash, the cernlib and miscellaneous other packages. I am also interested in TeX/LaTeX in Fedora and EPEL.
I maintain science packages, chm (Compiled Help Modules) related packages, perl modules, gnash, the cernlib and miscellaneous other packages. I am also interested in TeX/LaTeX in Fedora and EPEL.

Revision as of 22:54, 3 May 2010

Patrice Dumas

I have left Fedora, in Dec 2008, but I am still involved in EPEL.

I maintain science packages, chm (Compiled Help Modules) related packages, perl modules, gnash, the cernlib and miscellaneous other packages. I am also interested in TeX/LaTeX in Fedora and EPEL.

I tried to help integrating lightweight desktop and display managers in Fedora with the aim to have similar functionalities than with big desktops.

My personal homepage (mostly work, and in french) is here.

Proposals for updates after end of life

Some proposals for updates after end of life I tried to push forward:

Proposal for forced co-maintainership in case of ignored bug fixes (with Rahul)

No answer to bug fix policy.

On static library packaging for numerical and data processing

In the case of user compiled programs doing numerical computations or data analysis, using static libraries may be useful. Indeed it allows to build static executables that have more chance to be run on other platforms than the box they were compiled in, that have different dynamic library versions or even that don't have the library installed at all. At the same time those applications, in general, don't need the features brought in by shared libraries (no need for nss, no security issue, no need for iconv...). Therefore it may be acceptable or even desirable to ship static libraries for numerical and data processing libraries to help users needing to link statically their locally compiled executables. The static libraries still need to be in separate sub-packages and this doesn't means that the executables packaged in Fedora should be link statically, this is only for users linking locally their own programs.

Some packagers feel that this is not the right solution for locally compiled programs portability, since it is not general (doesn't work with nss, iconv...). However a general solution doesn't seems to exist yet. Also keep in mind that static subpackages take some space on the mirrors.

On not shipping shared libraries when upstream doesn't

For many reasons it is always preferable to have shared libraries, and the guidelines rightfully asks to avoid shipping static libraries. Sometime, however, the upstream project doesn't provide the rules for building shared libraries, only static libraries. In that case it is still possible to do some fedora specific modifications and additions to link dynamically. Linking dynamically involves setting a soname for the library, and rpmbuild will use that soname to compute the dependencies on the library. Now, if upstream later decides to build dynamically, it becomes possible that upstream uses the same soname for a binary incompatible library. This situation can easily lead to a mess where either one deviates from upstream for the soname, which is wrong, or one needs to hardcode library dependencies instead of depending on sonames, which is equally bad.

Therefore, I think that building shared libraries specifically in fedora should only be done when upstream won't add support for shared libraries in the future, or will do so taking into account the sonames chosen in fedora. Harmonizing with other distros would also be nice if a shared library is added.