packaging November 2009

packaging@lists.fedoraproject.org

37 participants
22 discussions

https://www.redhat.com/archives/fedora-packaging/2009-November/msg00052.html
by Tareq Al Jurf 19 Nov '09

19 Nov '09

The program is Invulgotracker 0.53.1 sorry if i opened a new thread because i'm using digest mode. -- Tareq Al Jurf Fedora Ambassador Riyadh, Saudi Arabia taljurf(a)fedoraproject.org

1 0

does removing a package also remove package data?
by John Dennis 18 Nov '09

18 Nov '09

I couldn't find this in the guidelines and I'm looking for clarification. When a package generates data as a consequence of it's runtime operation should the package data also be removed along with the package files when the package is uninstalled (i.e. rpm -e)? Issues: * It may be a user expectation that removing a package removes all the files associated with the package even if they are not package files (listed in %files). Most people remove packages because they don't want or need the package any more and don't want cruft left behind, they want a clean uninstall which recovers the maximum disk space possible without "orphans" * Generated data may have value after the package is removed, for some users it might be an unpleasant experience to discover after removing a package the data files were wiped out too. * It's not possible to query the user at uninstall time as to the disposition of data files because the uninstall (like install's) may be scripted. My inclination is the packaging guidelines should encourage the removal of data files generated by the package when the package is removed. Comments? -- John Dennis <jdennis(a)redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/

7 8

File path clarification
by Rich Mattes 18 Nov '09

18 Nov '09

I'm creating a package for a group of libraries, and I have a few questions about where to install some files. 1. The project creates its own folder in /usr/lib called /usr/lib/projectname, and installs its shared libraries there. What's the policy on doing this vs. putting all of the libraries into /usr/lib? 1a. The project also puts a few .cmake files in its libdir folder. Upstream informed me that some other projects use these files during their own build process, so moving these cmake files could be problematic. I think that putting .cmake files in /usr/lib might be a violation of linux filesystem rules, but doing a "yum provides *lib/*.cmake" shows that some other projects do this exact thing (install their libraries and cmake files into their own directory under /usr/lib). This leads me to believe that this practice is ok? 2. The project installs a bunch of other assorted cmake macros, which are also used by other projects. These don't take the form of FindProject.cmake though, so I don't think they belong in the system-wide cmake module path. I should put those in /usr/share/projectname/cmake? Thanks for the help, Rich

2 3

daemons vs services
by Orcan Ogetbil 17 Nov '09

17 Nov '09

Services need to be stopped before uninstallation of the corresponding package. How about daemons? Orcan

3 4

dont strip comments.
by Matt Sellers 17 Nov '09

17 Nov '09

Hi Everybody, I am trying to build a package that does not strip comments from the binary. example ( working ) : readelf -p .comment /usr/lib64/libnss_dns.so String dump of section '.comment': [ 1] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ 2e] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ 5b] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ 88] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ b5] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ e2] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ 10f] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) [ 13c] GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) The binaries that I build with rpmbuild see to be stripped: readelf -p .comment /usr/local/lib64/testlib.so readelf: Warning: Section '.comment' was not dumped because it does not exist! I can see that the comments are there before the binary is stripped for packing. My goal is to have a package stripped of debug symbols but keep the .comment section intact. This seems to be performed by the script in /usr/lib/rpm/find-debug.sh using "eu-strip", and while hacking this script is easy, I would like to enable this functionality in a more sane fashion if possible. Any and all suggestions greatly appreciated! Thank You, Matt

1 0

Duplicate files
by Jason L Tibbitts III 17 Nov '09

17 Nov '09

http://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files is pretty clear: ---- Duplicate Files A Fedora package must not list a file more than once in the spec file's %files listings. If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline. ---- However, some packagers absolutely insist on duplicating license files (say, once in the main package, and again in the -devel package) and this issue keeps coming up. Can we make a clear determination as to whether there are circumstances where duplication of license files is permitted, and clearly outline those situations in the guidelines? My understanding of the current opinion from the legal folks is that we must duplicate the license files if there's no clear dependency chain between the packages. Otherwise I think that we have enough duplicated copies of the GPL floating around and we should try to keep the number down where we can. - J<

5 9

Python 3 packaging
by David Malcolm 10 Nov '09

10 Nov '09

I'm working on a python 3 stack for Fedora 13, parallel-installable with the default python 2 stack [1] I've attempted to package python 3, and package some python modules for python 3. So far, I've got a "python3-rpm", a "python3-lxml", and two different ways of packaging "python3-setuptools", though none of these are actually in our CVS yet [2]. Thanks everyone for your help so far. In doing so, I've been writing some proposals on packaging guidelines for Python 3 - both for secondary python runtimes, and for modules for them. You can see what I've written so far here: https://fedoraproject.org/wiki/PackagingDrafts/Python3 Obviously this is a work in progress but hopefully makes sense as far as it goes. I've also written a script to cover some of the automatable work that can given python-foo.spec will write a python3-foo.spec You can see the script here: http://dmalcolm.fedorapeople.org/python3-packaging/rpm2to3.py I got over-ambitious with this script: it can also be given a target srpm, and will then checkout the python 2 srpm, convert to python 3, then recursively walk the build requirements, building the python 3 packages in mock, attemping to build all a stack all the way up to the given srpm... well, that was the theory. However, most packages seem to need at least a little manual cleanup, and so I never managed to get far up the stack - and this is no substitute for actually engaging with the various upstream projects and working on python 3 support in the manner that each upstream wants (e.g. do they want a unified trunk for 2 and 3 vs separate branches) Thoughts? Dave [1] https://fedoraproject.org/wiki/Features/Python3F13 [2] See https://bugzilla.redhat.com/showdependencytree.cgi?id=530636 for the full details.

1 0

Removing file from .spec
by Tareq Al Jurf 05 Nov '09

05 Nov '09

I have a spec file for a program that i'm packaging i was told to remove the INSTALL document from %files when i do that i get error: Installed (but unpackaged) file(s) found: > /usr/share/doc/invulgotracker/ >> >> INSTALL >> >> >> RPM build errors: >> Installed (but unpackaged) file(s) found: >> /usr/share/doc/invulgotracker/INSTALL > > what should i do? thanks -- Tareq Al Jurf Fedora Ambassador Riyadh, Saudi Arabia taljurf(a)fedoraproject.org

3 2

Fortran guideline issues
by Orion Poplawski 04 Nov '09

04 Nov '09

http://www.fedoraproject.org/wiki/Packaging:Fortran states: As Fortran modules are architecture and GCC version specific, they MUST be placed into %{_fmoddir} (or its package-specific subfolder in case the modules have generic names), which is owned by 'gcc-gfortran'. For directory ownership any packages containing Fortran modules MUST Requires: gcc-gfortran%{_isa}. I did this in netcdf, and ended up with: The following packages in the repository suffer from broken dependencies: ====================================================================== The results in this summary consider Test Updates! ====================================================================== package: netcdf-devel-4.0.1-2.fc11.i586 from fedora-updates-testing-11-x86_64 unresolved deps: gcc-gfortran(x86-32) package: netcdf-devel-4.0.1-2.fc11.ppc64 from fedora-updates-testing-11-ppc unresolved deps: gcc-gfortran(ppc-64) because gcc-gfortran (like gcc) is apparently not multi-lib. So, what to do? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

2 1

Proposal: naming convention for Python 3 packages and subpackages
by David Malcolm 04 Nov '09

04 Nov '09

(Resurrecting the "Proposal: Python 3 in Fedora 13" thread; see: https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html and https://fedoraproject.org/wiki/Features/Python3F13 ) On Thu, 2009-10-01 at 12:17 -0700, Toshio Kuratomi wrote: > On 10/01/2009 10:15 AM, David Malcolm wrote: [snip] > > "Naming convention" proposal: > > How does this sound: > > - an rpm with a "python-" prefix means a python 2 rpm, of the > > "default" python 2 minor version (for Fedora this will be the most > > recent stable upstream minor release, for EPEL it will be the minor > > release of 2 that came with the distro, so 2.4 for EPEL5) > > > > - an rpm with a "python3-" prefix means a python 3 rpm, of the > > "default" python 3 minor version (for Fedora this will be the most > > recent stable upstream release) > > > > What about packages without a "python-" prefix? Proposal: If upstream > > has a naming convention for python2 vs python3, use it. Otherwise, add > > a "python3-" prefix to make things clear. I'm not sure about the > > details here. Examples? > > > +1 to the basics. There are a lot of details to work out: Current naming conventions for Python packages are in https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.2… I rather like the idea of standardizing on a "python3-" prefix for _all_ Python 3 module packages and subpackages, even if this leads to inconsistencies with their counterparts in the python 2 stack. It would make the "threeness" of the packages stand out more. (NB: I hope that we'll eventually be in a place where we can cut over embedders and users of python (e.g. gedit, gdb, mod_python etc) from 2 to 3; I'm _not_ suggesting we do anything to their names. Obviously such a move is a long way off) > This seems fine even though it's a bit redundant: python3-pygtk2 and > python3-pygpgme. We could combine: - the "always use a python3-" rule I invented just above (ahem) and - the "When in doubt, use the name of the module that you type to import it in a script" advice from the python module guidelines. This would make the above examples be "python3-gtk" and "python3-gpgme" > What to do with things that have python in their suffix: > gstreamer-python => gstreamer-python3? Or python3-gstreamer? Or > python3-gstreamer-python? Most of these are subpackages of existing > packages. Again, following the combination of the two rules above: "python3-gstreamer" > A cornercase is the gnome-python2 package. These are python bindings to > gnome2. gnome-python2 is the upstream name. For python3, do we want > python3-gnome-python2, python3-gnome2, python3-gnome-python2 ? >From my reading of "rpm -qi gnome-python2", the upstream name is "gnome-python", so perhaps "python3-gnome" is the thing to use here? Thoughts? Dave

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging November 2009