RFC: init script naming
by Ville Skyttä
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?
17 years, 10 months
Mono Packaging (was Re: On the subject of sponsors...)
by Toshio Kuratomi
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_Unstabl...
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
17 years, 10 months
proper way to install emacs lisp add-ons?
by Zing
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
17 years, 10 months
new wiki-page: Packaging/FrequentlyMadeMistakes
by Thorsten Leemhuis
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>
17 years, 10 months
kernel module packaging
by Jon Masters
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.
17 years, 10 months