packaging February 2006

packaging@lists.fedoraproject.org

8 participants
4 discussions

PLEASE HELP - We need a policy for preventing man page name conflicts
by Orion Poplawski 21 Feb '06

21 Feb '06

Many packages provide man3 (and other) man pages with generic names. The case in question in ncarg-devel and allegro-devel which both provide man3/line.3.gz. So, what do we do? - package in /usr/share/<package>/man/? If so, how to we update MANPATH? How does man handle finding both (all) of the man pages? - rename to something like <package>_<manpage>? Do we always do this? Only if a file conflicts? Is there an easy way to find conflicts before packaging? - suffixes <manpage>.3<suffix> ? Can man handle this? Please help! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com

5 6

Re: [Fedora-packaging] Re: PLEASE HELP - We need a policy for preventing man page name conflicts
by Orion Poplawski 20 Feb '06

20 Feb '06

Ivan Gyurdiev wrote: > > I suggest efforts would be better directed at fixing the real problem - > i.e. the library namespace. > > Having an API that calls functions line() and such means it's just a > question of time before you run into header conflicts where a program > attempts to include two headers with the same function name (or > statically link against two libraries with the same symbol, whether the > function is used or not)... or link against the library and have a local > function called line() defined. > > I suppose programming language makes a difference here, but at least > this should apply to C code. > Yes, things should get fixed upstream. But in the meantime, we're packaging this stuff and need a policy for a workaround. I'm inclined to rename all man3 functions to ncarg_<name> to fix my particular issue. I'll file a note upstream as well. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com

1 0

Re: [Fedora-packaging] Re: PLEASE HELP - We need a policy for preventing man page name conflicts
by Ralf Corsepius 20 Feb '06

20 Feb '06

On Mon, 2006-02-20 at 09:17 -0500, Ivan Gyurdiev wrote: > > Works for section 3 but not for section 1 (application man packages). > > There, each man page should match the name of the tool it is trying to > > describe. > > > > But, if section 1 man pages clash, the apps probably also do. > > > And in section 3 they don't? section 3 contains library API docs, corresponding to libraries. While apps must be unique, and libraries and the APIs not necessarily are. There may well be reasons why one API can be implemented by several library. > I suggest efforts would be better directed at fixing the real problem - > i.e. the library namespace. This doesn't work - Check the Inventor and Coin2 examples I tried to point you to. They both implement the same API (Coin2 is a clone of Inventor), both packages can be installed in parallel and do not conflict. Both are licensed differently (LGPL vs. GPL), nor are both libraries technically 100% compatible. I.e. there are good reasons to have them both. Ralf

1 0

fontname-fonts or fonts-fontname?
by Dawid Gajownik 08 Feb '06

08 Feb '06

Hi! Houston, we've got a problem ;) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179439#c7 Do we have any naming guidelines concerning packages with fonts? There is some inconsistency: [y4kk0@X ~]$ repoquery -qa | grep fonts bitmap-fonts-0:0.3-4.noarch fonts-gujarati-0:1.10-2.noarch fonts-tamil-0:1.10-2.noarch fonts-xorg-ISO8859-14-75dpi-0:6.8.2-1.noarch fonts-bengali-0:1.10-2.noarch fonts-xorg-ISO8859-15-75dpi-0:6.8.2-1.noarch kon2-fonts-0:0.3.9b-26.i386 fonts-japanese-0:0.20050222-3.noarch fonts-xorg-ISO8859-9-75dpi-0:6.8.2-1.noarch fonts-xorg-syriac-0:6.8.2-1.noarch gentium-fonts-0:1.02-2.noarch hunky-fonts-0:0.3.1-2.fc4.noarch taipeifonts-0:1.2-26.noarch ghostscript-fonts-0:5.50-13.noarch fonts-KOI8-R-100dpi-0:1.0-7.noarch fonts-ISO8859-2-0:1.0-14.noarch fonts-arabic-0:1.5-3.noarch mgopen-fonts-0:0.20050515-1.noarch fonts-xorg-ISO8859-9-100dpi-0:6.8.2-1.noarch tetex-fonts-0:3.0-9.FC4.i386 fonts-xorg-cyrillic-0:6.8.2-1.noarch fonts-punjabi-0:1.10-2.noarch fonts-hebrew-0:0.100-4.noarch fonts-chinese-0:2.15-2.noarch fonts-hebrew-fancy-0:0.101-2.fc4.noarch fonts-ISO8859-2-75dpi-0:1.0-14.noarch fonts-hindi-0:1.10-2.noarch bitmap-fonts-cjk-0:0.3-4.noarch fonts-xorg-base-0:6.8.2-1.noarch dejavu-fonts-0:2.2-3.fc4.noarch fonts-xorg-100dpi-0:6.8.2-1.noarch fonts-ISO8859-2-100dpi-0:1.0-14.noarch fonts-korean-0:1.0.11-4.noarch fonts-xorg-75dpi-0:6.8.2-1.noarch fonts-xorg-ISO8859-15-100dpi-0:6.8.2-1.noarch urw-fonts-0:2.3-1.noarch fonts-KOI8-R-0:1.0-7.noarch mplayer-fonts-0:1.1-0.lvn.3.4.noarch fonts-xorg-ISO8859-2-100dpi-0:6.8.2-1.noarch fonts-KOI8-R-75dpi-0:1.0-7.noarch fonts-xorg-ISO8859-2-75dpi-0:6.8.2-1.noarch fonts-xorg-truetype-0:6.8.2-1.noarch fonts-xorg-ISO8859-14-100dpi-0:6.8.2-1.noarch bitstream-vera-fonts-0:1.10-5.noarch mathml-fonts-0:1.0-19.fc4.noarch [y4kk0@X ~]$ Thanks, Dawid -- ^_*

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2006