packaging June 2006

packaging@lists.fedoraproject.org

31 participants
26 discussions

RFC: init script naming
by Ville Skyttä 12 Jun '06

12 Jun '06

rpmlint currently whines if a package installs one init script, and the init script name doesn't match the package name. If more than one init scripts are installed from one package, it doesn't emit this warning. I don't think there are any naming guidelines for init scripts currently in effect, so I'm wondering if I should just filter out the warning in future rpmlint package revisions, or if people think that the way rpmlint currently wants the init scripts named would be make a good packaging guideline. Thoughts?

4 3

libtool archives (.la files) and rpm packaging
by Rex Dieter 09 Jun '06

09 Jun '06

Had some spare cycles today, so thought I'd share my highly editorial take on libtool .la file with the world. Enjoy. http://www.math.unl.edu/~rdieter1/libtool-archives-suck.html (Don't take it too seriously... well, a little bit...) -- Rex

2 1

Mono Packaging (was Re: On the subject of sponsors...)
by Toshio Kuratomi 08 Jun '06

08 Jun '06

On Thu, 2006-06-08 at 10:18 +0100, Paul Howarth wrote: > > I'm still looking for mono packaging standards to be sorted out; for > instance, the %{_libdir} hack is still under debate, as is a move to put > mono stuff under %{_datadir}. Are we collecting the open questions about packaging mono apps anywhere? http://www.fedoraproject.org/wiki/Packaging/Mono seems to be an instruction manual for packaging mono rather than a lit of questions we need to solve (and lists the _libdir hack as a solution a bit prematurely, IMHO) Another open question would be how this affects us: http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_… It's advocating using .dlls with unstable APIs the same way we normally use static libraries (including a local copy with the application). It has all the usual features of a static library scheme but fails to mention any security issues. Should packages entering Fedora be checked to make sure they *do not* follow this or are mono .dlls immune to the security concerns with normal static libraries? PS: This is moving into general packaging territory so I'm cross-posting it to fedora-packaging. Replies to fedora-packaging please. -Toshio

1 0

proper way to install emacs lisp add-ons?
by Zing 07 Jun '06

07 Jun '06

I'm looking into packaging gtypist, which has an emacs add-on: gtypist-mode.{el,elc} I'd like to just put %{_datadir}/emacs/site-lisp/* in %files and be done with it but this seems to go in direct opposition to the following: ================================================================ http://fedoraproject.org/wiki/Packaging/ReviewGuidelines MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard ([WWW] http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. ================================================================= So I can (in my personal ascending in preference): 1. Require: emacs (this doesn't seem reasonable for people who don't use emacs since the lisp add-ons are usually optional) 2. do something like cscope and use triggers (just say no to triggers). 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, but is there a naming guideline for this situation? What would the name be? Is this worth the effort?) or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :) zing

5 13

new wiki-page: Packaging/FrequentlyMadeMistakes
by Thorsten Leemhuis 05 Jun '06

05 Jun '06

Hi! Just FYI: I created a new page in the wiki at http://www.fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes I'd like to collect and describe some common and frequently made mistakes there that happen while packaging RPM-Files and putting them under review for Extras. Maybe that helps one or two packagers to avoid those mistakes. Currently it only lists three common problems that afaics new packagers often make -- but I'm sure there are many others so feel free to add them on the page. There are probably also some general mistakes that even experienced packagers tip into now and then -- please write them up on the page, too. tia CU thl -- Thorsten Leemhuis <fedora(a)leemhuis.info>

1 0

kernel module packaging
by Jon Masters 05 Jun '06

05 Jun '06

Hi folks, I'm working on some to-be-proposed updates to the kernel module packaging in Fedora Extras to allow us to track changes to the kernel ABI rather than purely the kernel release/version. This should make life easier and help to reduce the number of times that a minor kernel update (e.g. security fixes, etc.) forces all external drivers to be rebuilt. At http://www.kerneldrivers.org/ I have some sample packages that I'm working on, as well as a description of the process and how this relates to other Linux distributions, such as SuSE. I'm going to continue working on this, keep the wiki updated, and ultimately ask FESCo pretty soon if we can make a few minor changes to kmodtool and get this out there. Obviously, I'm very keen to hear from anyone else who wants to help :-) Thanks! Jon.

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2006