does removing a package also remove package data?
by John Dennis
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/
14 years, 4 months
File path clarification
by Rich Mattes
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
14 years, 4 months
daemons vs services
by Orcan Ogetbil
Services need to be stopped before uninstallation of the corresponding package.
How about daemons?
Orcan
14 years, 4 months
dont strip comments.
by Matt Sellers
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
14 years, 4 months
Duplicate files
by Jason L Tibbitts III
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<
14 years, 4 months
Python 3 packaging
by David Malcolm
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.
14 years, 4 months
Removing file from .spec
by Tareq Al Jurf
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
14 years, 4 months
Fortran guideline issues
by Orion Poplawski
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
14 years, 4 months
Proposal: naming convention for Python 3 packages and subpackages
by David Malcolm
(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_...
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
14 years, 4 months