packaging January 2008

packaging@lists.fedoraproject.org

35 participants
22 discussions

[Fwd: Re: [Fedora-packaging] Lisp packaging draft]
by Toshio Kuratomi 29 Jan '08

29 Jan '08

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

1 0

rpc service description headers packaging
by Patrice Dumas 28 Jan '08

28 Jan '08

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

2 1

pike packages
by josef radinger 24 Jan '08

24 Jan '08

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

2 1

help on PreReq and trigges for texinfo
by Patrice Dumas 22 Jan '08

22 Jan '08

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

2 1

tex/latex doc install location
by Patrice Dumas 21 Jan '08

21 Jan '08

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

7 9

Conditionally building a sub-package?
by James Laska 21 Jan '08

21 Jan '08

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. ==========================================

2 2

Reviewing an existing package with major changes
by Bruno Postle 21 Jan '08

21 Jan '08

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

3 2

Lisp packaging draft
by Anthony Green 19 Jan '08

19 Jan '08

For your review... http://fedoraproject.org/wiki/PackagingDrafts/Lisp AG

2 1

Possible restructuring of docbook-related packages?
by Robert P. J. Day 16 Jan '08

16 Jan '08

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 ========================================================================

2 2

bootstrapping for scala
by Geoff Reedy 16 Jan '08

16 Jan '08

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?

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging January 2008