Modifying upstream tarballs
by Jason L Tibbitts III
I understand that there are circumstances where the upstream tarballs
need to be modified to removed content which is patented or cannot be
redistributed for some reason. However, should that be the extent of
the permitted modifications?
Take, for example, this comment from a current review ticket:
#Original from http://membres.lycos.fr/agisite/prof.zip includes
#copyrighted executables. Generated new source by unzipping, removing
#DOS-related content, running dos2unix on the text file, and changing
#all filenames to lowercase for agistudio compatibility.
Now, everything except the removal of the executables could be done at
%prep time in the spec, and that's how we'd insist that things be done
in the normal case where the upstream tarball (or zipfile, in this
case) needs no modification.
- J<
16 years, 9 months
Call rpm during rpmbuild
by Richard W.M. Jones
I'm right in thinking that it's bad to call rpm from rpmbuild?
During my find-requires script, I need to get the exact
name-version-release of the ocaml compiler. Obviously the compiler
knows its name & version, but not its release.
At the moment I'm doing:
if [ -n "$emit_compiler_version" ]; then
# Every OCaml program depends on the precise version of the
# compiler which was used to compile it.
rpm -q --qf '%{NAME} = %{VERSION}-%{RELEASE}\n' ocaml
fi
but if calling rpm like this is bad, I'm wondering how to fix it. Best
way I can see to do this is to store the name-version-release of the
compiler in a special file in the ocaml RPM, something like:
/usr/lib64/ocaml/fedora-ocaml-release
which would contain something like 3.09.0-3 or whatever, then the script
can be changed to cat this file.
What do people think?
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
16 years, 10 months
Missing Packaging Meeting
by Toshio Kuratomi
I'll be in a training meeting and won't be able to make the meeting this
Tuesday.
-Toshio
16 years, 10 months
Script to check gnomefiles.org for upstream updates
by Sindre Pedersen Bjordal
Hope this is the right list.
Lots of upstream projects use gnomefiles.org, several of the packages I
maintain use it to post news about updates.
Gnomefiles.org offers a nice automatically generated XML document for
accessing the version information. Inspired by the cpancheck.sh script
for perl packages I wrote, with a lot of help from friendly people on
irc, a script to check if packages maintained by a given user have
version information on GnomeFiles and more importantly, if the version
in fedora devel and GnomeFiles.org match. This way you can run this
script and see if there's a new release of one of your packages.
Like with the cpancheck.sh script you'll have to define your email, path
to owners.list and path to your local Fedora cvsroot in the script
itself.
Script available here:
http://folk.ntnu.no/sindrb/fedora/gnomefilescheck.sh
Feedback very welcome, hope this is useful for someone besides me.
--
Sindre Pedersen Bjørdal <foolish(a)guezz.net>
- http://www.fedoraproject.org/wiki/SindrePedersenBjordal
16 years, 10 months
paragraph on shipping static numerical libs updated
by Patrice Dumas
Hello,
Here is an updated version of the paragraph about shipping static
numerical libs taking into account the comments on the first version.
The objective is to have this included in
http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges
at the end of 'Packaging Static Libraries'.
* in the case of user compiled programs doing numerical computations or
data analysis, using static libraries may be useful. Indeed it allows
to build static executables that have more chance to be run on other
platforms than the box they were compiled in, that have different
dynamic library versions or even that don't have the library installed
at all. At the same time those applications, in general, don't need
the features brought in by shared libraries (no need for nss, no
security issue, no need for iconv...). Therefore it may be acceptable
or even desirable to ship static libraries for numerical and data
processing libraries to help users needing to link statically their
locally compiled executables. The static libraries still need to be
in separate sub-packages and this doesn't means that the executables
packaged in Fedora should be link statically, this is only for users
linking locally their own programs.
Some packagers feel that this is not the right solution for locally
compiled programs portability, since it is not general (doesn't work
with nss, iconv...). However a general solution doesn't seems to exist
yet.
--
Pat
16 years, 10 months
tricks for multilib proposal
by Patrice Dumas
Hello,
I propose the following with tricks for packaging multilibs. It tries to
be a summary of a thread about multilibs. There may be mistakes, or
statements everybody doesn't agree with, so please comment.
This is pseudo wiki and I don't know where it should be put in the
wiki.
= Multi lib tricks =
== Architecture independent files ==
For architecture independent the conflicts should be avoided, so the
files should be identical among arches. It may involve some work with
upstream when header files include architecture specific files, for
example header files which contains autoconf conditionals like
HAVE_INT32.
Files should also have the same timestamps. For most of the files this
means taking care to keep the timestamps (which should be done in
every package). For autoconf based packages this is in general achieved
by doing something along:
make install DESTDIR=$RPM_BUILD_ROOT INSTALL="%{__install} -p"
For the architecture independent files generated at build time it is
possible to use the timestamp of a reference file. For example:
touch -r ../cernlib.in src/scripts/cernlib
or
touch -r NEWS $RPM_BUILD_ROOT%{_includedir}/Xbae/patchlevel.h
== Multiarch, binaries and compilation scripts ==
In multilib environments there is a preferred architecture, 64
bit over 32 bit in x86_64, 32 bit over 64 bit in ppc64. When a conflict
is found between two packages corresponding with different arches, the
installed file is the one from the preferred arch. This is very common
for executables in /usr/bin, for example. If the file /usr/bin/foo is
found in an x86_64 package and in an i386 package, the executable
from x86_64 will be installed.
These implicit conflicts are accepted in Fedora, though they are
considered bad by some contributors. There may be some long-term
solution for these issues, but before that there are some tricks
that may allow to avoid those conflicts that are presented below.
Once again they are optional.
* In compilation scripts (in general named along mylib-config) it should
be advisable to remove -L$libdir when $libdir is the default library
directory on this platform. Indeed this is automatically added when
linking with the gcc compiler (it may be needed when linking with ld,
but using ld is wrong in general, so a user linking with ld should add
the flag by himself).
* binaries may be put outside of the packages selected to be included
in multilib repositories. In general the devel subpackages and their
dependencies are included in multilib repositories. A typical split
of a package is:
foo for the binaries
foo-libs for the libraries
foo-devel for the development headers, and development symlinks
foo-devel and foo both requires foo-libs, and foo isn't
present in multilib repository.
* wrapper scripts may be used to run a binaries based on which one is
present. Here is a script example (adapted from firefox)
ARCH=$(uname -m)
case $ARCH in
x86_64 | ia64 | s390 )
LIB_DIR=/usr/lib64
SECONDARY_LIB_DIR=/usr/lib
;;
* )
LIB_DIR=/usr/lib
SECONDARY_LIB_DIR=/usr/lib64
;;
esac
if [ ! -x $LIB_DIR/package-0.0.1/foo ]; then
if [ ! -x $SECONDARY_LIB_DIR/package-0.0.1/foo ]; then
echo "Error: $LIB_DIR/package-0.0.1/foo not found"
if [ -d $SECONDARY_LIB_DIR ]; then
echo " $SECONDARY_LIB_DIR/package-0.0.1/foo not found"
fi
exit 1
fi
LIB_DIR=$SECONDARY_LIB_DIR
fi
Another way to handle those conflicts could be to have a different
directory for each architecture, even for executables, enabling
Fedora to be multiarch and not only multilib.
--
Pat
16 years, 10 months