[Fwd: Re: [Fedora-packaging] Lisp packaging draft]
by Toshio Kuratomi
Hey Anthony, It just occurred to me that you might not be on the
packaging list so I thought I better resend this to you.
-------- Original Message --------
Subject: Re: [Fedora-packaging] Lisp packaging draft
Date: Fri, 18 Jan 2008 17:42:33 -0800
From: Toshio Kuratomi <a.badger(a)gmail.com>
To: Discussion of RPM packaging standards and practices for Fedora
<fedora-packaging(a)redhat.com>
References: <4791022A.2080103(a)redhat.com>
Anthony Green wrote:
> For your review...
>
> http://fedoraproject.org/wiki/PackagingDrafts/Lisp
>
Cool. Thanks for taking charge of this.
A bit of feedback: High level:
* The guidelines need to be written so that a reviewer can effectively
use them to decide if a package is conforming. This means that you
might have to explain things that the packager will understand (since
they come from a lisp background) but the reviewer might not.
Specifics:
* What is adsf? Is it a format or a utility? If the former, how do we
get libraries into that format, if the latter, how and when do we invoke it?
* What differentiates a lisp library from another piece of lisp?
* How do the various register/unregister commands translate to
%post/%preun scriptlets?
* What package are the register/unregister commands provided in?
* What package provides /usr/lib/common-lisp?
* What package provides /usr/share/common-lisp?
* Why do we use /usr/lib/common-lisp instead of /usr/libexec/common-lisp?
* What are fasls?
* What provides /var/cache/common-lisp-controller?
* What is being created in
/var/cache/common-lisp-controller/<userid>/<implementation>/<library>/ ?
* What creates those directories? Who creates those directories?
* You mention compiling of libraries. Where do those get dropped on the
system? What are the commands to generate those during %build?
* It looks like some of the Debian Guidelines aren't going necessary for
Fedora... for instance::
{{{
- register-common-lisp-source:
does nothing
}}}
In Fedora, we try to avoid doing things that are no-ops.
I'm sure there will be more questions after these are answered and
incorporated into your draft :-)
-Toshio
15 years, 10 months
rpc service description headers packaging
by Patrice Dumas
Hello,
There is some dissension on the packaging of the rpc service headers that
comes with quota
/usr/include/rpcsvc/rquota.h
/usr/include/rpcsvc/rquota.x
see
https://bugzilla.redhat.com/show_bug.cgi?id=226353
The same issue exists for ypserv for
/usr/include/rpcsvc/ypxfrd.x
All the remaining service header files are owned by glibc-headers.
Reviewers insist on putting those files in a -devel subpackage. I am not
sure that it is really needed since these are not API description. The
devel package won't need to require the main package, and it seems to me
that it would better be called -headers than -devel. Also maybe all the
rpc service headers could be in glibc.
Advices?
--
Pat
15 years, 10 months
pike packages
by josef radinger
Hello,
I currently work on creating pike-packages.
the next lines of text are shameless ripped from
http://pike.ida.liu.se/about/
Pike is a general purpose programming language, which means that you can
put it to use for almost any task. Its application domain spans anything
from the world of the Net to the world of multimedia applications, or
environments where your shell could use some spicy text processing or
system administration tools. Your imagination sets the limit, but Pike
will probably extend it far beyond what you previously considered within
reach.
the - in my opinion - main application using pike is caudium/roxen,
which is a cool webserver, i personally use since years and love to use
it. creating caudium-packages would be my next step.
to be honest, there are problems too:
there are not enough developers to keep up with new developments, but
theses days this seems to improve and would improve further, if
fedora-users would join in as deveopers AND as endusers (without the
obstacle to compile pike).
I would need someone willing to review the pike-packages.
yours
josef
ps.: i did not send a link to the packages, as those are currently
somewhat rough and i need to find some time to work around the biggestr
problems, before showing them to the public.
pps.: i wanted to send this after the packages where ready, but i never
got to that point, and now i have to finish them, as hopefully i get
some response from the list.
ppps.: http://www.caudium.net is currently under rework
15 years, 10 months
help on PreReq and trigges for texinfo
by Patrice Dumas
Hello,
In texinfo, for the info subpackage that contains /sbin/install-info,
there is:
# By making info prereq bash, other packages which have triggers based on
# info don't run those triggers until bash is in place as well. This is an
# ugly method of doing it (triggers which fire on set intersection would
# be better), but it's the best we can do for now. Talk to Erik before
# removing this.
Prereq: bash
I have found
http://people.redhat.com/laroche/pyrpm/pyrpm-devel.html
which states that triggers are run after %post. So I think that it could
be replaced by
Requires(post): bash
But it also seems that rpm adds automatically a Requires(post): /bin/sh
for packages that have a %post. So it even seems to me that this can be
entirely dropped.
Advices?
--
Pat
15 years, 10 months
tex/latex doc install location
by Patrice Dumas
Hello,
In tex/latex bundled in fedora (I guess it comes from tetex and it is
now in texlive) there is a simple system to view documentation. The
files are found below /usr/share/texmf/doc using kpathsea (so hopefully
rapidly) and opened using the appropriate application (currently using
xdg-open for everything...).
In fedora should we use this system and put the doc files below
/usr/share/texmf/doc/ or use %doc?
--
Pat
15 years, 10 months
Conditionally building a sub-package?
by James Laska
Greetings,
Looking for a recommendation or thoughts around resolving a EPEL deps
issue noted in bug#429479.
The snake package contains a server and client utility. The client is
intended to run on distribution from FC3 and newer. The server must be
run in an environment that includes pykickstart >= 1.1. At this time,
this means anything newer than FC7.
In bug#429479 it was discussed that conditionally building the
sub-package on environments < FC7 was a good method to avoid EPEL deps
issues.
My plan was to implement something like the following:
%define has_pykickstart_version %{python -c "import
pykickstart.version;" 2>/dev/null && echo "1" || echo "0"}
%if %{has_pykickstart_version}
...
%endif
Do folks have any experience or recommendations in the realm of
conditional sub-package builds?
Thanks,
James
--
==========================================
James Laska -- jlaska(a)redhat.com
Quality Engineering -- Red Hat, Inc.
==========================================
15 years, 10 months
Reviewing an existing package with major changes
by Bruno Postle
Not sure if this is the right list for this question. Sorry I can't
find anything about this in the wiki.
I'm planning on updating the hugin package, but there have been so
many changes that the spec file is largely rewritten - I've split
out a hugin-base sub-package, the build system has changed to cmake,
there are now .so libraries etc...
Should I submit a bugzilla review request even though this is an
'old' package?
--
Bruno
15 years, 10 months
Possible restructuring of docbook-related packages?
by Robert P. J. Day
i'm wondering if there might be some benefit to repackaging some of
the docbook-related packages.
first, there are the two "utils" packages:
docbook-utils
docbook-utils-pdf
it seems awkward to have one package advertising itself as "utils",
only for some of those utils to be broken off and put in a more
specific package, which wouldn't be obvious to anyone who simply saw
"docbook-utils" and figured that's all he needed.
more to the point, that second package contains additional utilities
anyway:
$ rpm -ql docbook-utils-pdf
/usr/bin/db2dvi
/usr/bin/db2pdf
/usr/bin/db2ps
/usr/bin/docbook2dvi
/usr/bin/docbook2pdf
/usr/bin/docbook2ps
/usr/share/man/man1/db2pdf.1.gz
/usr/share/man/man1/docbook2dvi.1.gz
/usr/share/man/man1/docbook2pdf.1.gz
/usr/share/man/man1/docbook2ps.1.gz
$
so there's DVI and PS stuff in there as well -- certainly not obvious
from the package name. is there some reason this can's just be all in
one package?
also, is there any clean way to separate the SGML and XML stuff in
the docbook-dtds package? even the XML DTDs for docbook are under
/usr/share/sgml. does XML processing still require underlying
functionality? if not, is there no way to separate all of that into
SGML versus XML content, and perhaps load only the XML-related
packages if that's all one needs?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook: http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
========================================================================
15 years, 10 months
bootstrapping for scala
by Geoff Reedy
I am working on a package (BZ#426867) for scala
(http://www.scala-lang.org) that requires bootstrapping with a
previously compiled toolchain. According to the Packaging Guidelines
this package requires approval from the Packaging Committee for
inclusion in fedora since pre-built components are require to build the
package from source. The Packaging/Committee page on the wiki leads me
to believe this is the appropriate forum to do so. What steps need to
happen to get this approval?
15 years, 11 months
