Tcl packaging guidelines proposal
by Michael Thomas
I sent this proposal to f-m-l about a week ago to gather comments, and
there were no serious disagreements with the proposal which have not yet
been addressed (thanks to Tibbs and Toshio for their feedback).
Basically, I want to establish a set of guidelines for packaging Tcl
extensions, as we already have guidelines for other popular scripting
languages. In addition to making Tcl packages more consistent with each
other, it will also help work toward fixing my pet-peeve bug (bz #226893)
http://fedoraproject.org/wiki/PackagingDrafts/Tcl
Please let me know if I need to do anything to help get these draft
guidelines adopted.
Thanks,
--Wart
15 years, 11 months
Hardlinking *.pyc and *.pyo
by Ville Skyttä
Hello,
Related to recent space saving discussions, I came across PLD's
rpm-build-macros package recently, and found that they hardlink
identical *.pyc and *.pyo. In a lot of cases, they're the same,
and there's some potential for saving some MB "for free",
on my FC6 x86_64 box:
$ /usr/sbin/hardlink -ncv /usr/lib*/python2.4 2>&1 | tail -n 1
Would save 11116544
The PLD implementation looks like this:
# Hardlink binary identical .pyc and .pyo files
# (idea by glen <at> pld-linux <dot> org)
%__spec_install_post_py_hardlink {\
%{!?no_install_post_py_hardlink: __spec_install_post_py_hardlink() { \
[ ! -d "$RPM_BUILD_ROOT" ] || find "$RPM_BUILD_ROOT" -name '*.pyc' | while read a; do \
b="$(echo $a|sed -e 's/.pyc$/.pyo/')"; \
if cmp -s "$a" "$b"; then \
ln -f "$a" "$b"; \
fi; \
done \
}; __spec_install_post_py_hardlink } }
The use of "cmp" would require diffutils installed. Or the above
could be converted to use hardlink instead (which would have to be made
sure to be around) or maybe sha1sum (in coreutils, pretty much always
around in buildroots).
I suppose something like the above could be easily added to
redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile
or run after it in %__os_install_post.
Worth it? Other comments?
16 years, 5 months
OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)
by Richard W.M. Jones
Toshio Kuratomi wrote:
> On Sun, 2007-04-15 at 23:53 +1200, Nigel Jones wrote:
>> Nigel Jones wrote:
>> > Hi everyone,
>> >
>> > While putting in a couple of packages for Extras Review I've stumbled
>> > into a couple of issues regarding how Ocaml links libraries and how the
>> > Fedora Packaging Guidelines are set.
>> >
>> > My packages in question are:
>> > ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804)
>> > camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805)
>> > freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815)
>> >
>> > Basically, ocamlSDL and camlimages produce two sets of libraries (a set
>> > of dynamic libraries, and another set for development etc), sadly when
>> > other packages like freetennis build, they staticly link to libraries
>> > such as camlimages/ocamlSDL.
>> >
>> > I found it semi-suspect when I built freetennis, and hence why I asked
>> > on bugzilla when I posted the three packages for review, however I did
>> > some more questioning today and after a quick IRC discussion in #ocaml
>> > was told:
>> >
>> > 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries
>> > right?
>> > 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes.
>> > 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading.
>> > 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for
>> > dynamic loading as static loading.
>> >
>> > Looking at my installed files on my laptop, lablgl, lablgtk and labltk
>> > (as well as the main ocaml package) store .a, .cma and .cmxa files in
>> > /usr/lib/ocaml (and subfolders).
>> >
>> > As I'm only new to Fedora packaging, could someone please advise on
>> > where I should from here on the matter and what the position of FESCO is
>> > on Ocaml static libraries, and where I should go from here.
>> >
>> > Thanks,
>> >
>> > Nigel Jones
>>
>> I'm just wondering if anyone has any thoughts on this issue.
>>
>> I've talked to some more people in #ocaml (Freenode), who suggested that
>> I try a patch by the name of 'scaml' which is a year or two old (and
>> although can be manually applied to the ocaml source, it does not work
>> (problems with assembly which I've not comfortable meddling with).
>>
>> We'd actually need to downgrade to 3.07 which was removed from Fedora in
>> Feb 05 to get the patch working to satisfy the need for dynamic loading
>> which I'm sure would upset a few people.
>>
>> Upstream already have a bug opened stating that they need to fix the
>> issue but they have never updated it, or assigned it to anyone.
>>
>> So my main question is "where to from here?"
>
> I think, if the ocaml compiler doesn't support dynamic libraries, static
> linking would be acceptable. This doesn't mean that we shouldn't press
> upstream to add dynamic linking (and convert all our packages when that
> becomes available) just an acknowledgment that fixing the limitation has
> to be done upstream (it could be done by someone within Fedora but the
> fix needs to go upstream).
>
> This is similar to allowing C libraries in even if they only build
> statically.
>
> If I'm not understanding precisely what the limitation is, feel free to
> clarify.
There are two issues here: (a) Having OCaml binaries link dynamically
instead of statically to OCaml libraries. (b) Writing a dynamic library
in OCaml, and having it used by programs written in other languages,
particularly C.
I suspect it's unlikely that upstream will do (a), ever. There's a
technical issue. OCaml really doesn't have a concept of an ABI. It
does a kind of whole-program optimisation where even changes to the
internal implementation of a library can affect the resulting binary.
Moreover even if you "fixed" that, any change whatsoever to the
library's signature or the version of compiler it was built with (even
bugfix releases which have the same version number) will make the
library incompatible.
You might also find this entertaining:
http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cb...
Another issue which Xavier doesn't mention is the ability to fix a
security bug in a shared library, and not require all dependent
applications be recompiled. Well, there aren't many (any?) widely used
OCaml libraries, and there aren't a lot of binaries which would need to
be recompiled either. But it could be a problem for OCaml world
domination plans.
As for (b), the ability to write libraries in a sane language and have
them called through a C API: This almost works. Well, it works well on
i386, but there are some problems on x86-64. I'm looking forward to
having this. It needs some tools to make it work well - it would be
nice to have the C header files and the complex Makefile fragments to
get it to work generated automatically.
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, 5 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, 6 months
paragraph on shipping static numerical libs
by Patrice Dumas
Hello,
Here is a paragraph explaining why some libs may be usefull in their
static version:
* 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.
--
Pat
16 years, 6 months
Meaning of -devel
by Richard W.M. Jones
Is there a policy which describes precisely what should go into a -devel
subpackage?
Here is an example case where I'm unsure:
In OCaml there's a thing called the "toplevel". Think of it as being
like the python command line (where you just type "python" on its own,
then start typing in Python expressions).
$ ocaml -I +calendar
Objective Caml version 3.09.3
# #load "unix.cma";;
# #load "str.cma";;
# #load "calendar.cma";;
# let d = Printer.DatePrinter.from_string "2007-01-01";;
val d : Printer.DatePrinter.t = <abstr>
# Printer.DatePrinter.to_string (Date.next d `Week);;
- : string = "2007-01-08"
So my question: If I'm packaging ocaml-calendar (a library) then should
the parts which make the above possible go into the main package or
ocaml-calendar-devel?
Note that as far as I can see in Python -- and I'm not hugely familiar
with that language so forgive me if I've made a mistake -- but it seems
they go in the main package.
Another thing is that if I move the parts into the -devel subpackage,
then ocaml-calendar will literally be empty!
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, 6 months
Exit status in rpm scriptlets
by Miroslav Lichvar
>From http://fedoraproject.org/wiki/Packaging/ScriptletSnippets:
"Most commands in the snippets in this document have a "|| :" appended
to them. This little piece of code causes each such command to exit
with a successful exit status whether or not the command worked. This
is important because the scriptlet as a whole will error the moment it
tries to execute a command that has a non-zero exit status."
That's not quite correct, at least with rpm we have in Fedora.
Scriptlets (contrary to build scripts) are not actually executed
through sh -e, therefore a failed command won't cause the whole
scriptlet to fail. Only the last command executed matters.
Generally we want to have scriptlets that always succeed, so added
"|| :" doesn't break anything, but in case where we want to fail the
installation of the package (as in UsersAndGroups packaging draft that
wants to abort installation if required user isn't available) this
doesn't work as one might expect.
For scriptlets that should always return 0 just add : as the last line
of the script and add "|| exit 1" to a command that should abort the
whole script when failed.
--
Miroslav Lichvar
16 years, 6 months
Draft Changes to static libraries
by Toshio Kuratomi
I've written a draft of changes to the static library guidelines::
http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges
There are three pieces which can be voted on separately or together
depending on how controversial they are:
1) Separate static library inclusion from static library linkage and
make static library inclusion less strict.
2) Change how to package static libraries when the package does not
include dynamic libraries (per Ralf's note to the list)
3) Incorporate mschwendt's note about *.la files directly into the
guidelines instead of as a footnote.
Comments welcome.
== Exclusion of Static Libraries ==
Packages including libraries should exclude static libs as far as
possible (eg by configuring with ''--disable-static''). Static
libraries should only be included in exceptional circumstances.
Applications linking against libraries should as far as possible link
against shared libraries not static versions.
Libtool archives, ''foo.la'' files, should not be included. Packages
using libtool will install these by default even if you configure with
''--disable-static'', so they may need to be removed before packaging.
Due to bugs in older versions of libtool or bugs in programs that use
it, there are times when it is not always possible to remove *.la files
without modifying the program. In most cases it is fairly easy to work
with upstream to fix these issues.
=== Packaging Static Libraries ===
* In general, packagers are strongly encouraged not to ship static libs
unless a compelling reason exists.
* We want to be able to track which packages are using static libraries
(so we can find which packages need to be rebuilt if a security flaw in
a static library is fixed, for instance.)
* When a package provides both dynamic and static libraries the static
libraries must be placed in a ''*-static'' subpackage. Separating the
static libs from the other development files in ''*-devel'' allow us to
track this usage by checking which packages Build''''''Require the
''*-static'' package.
* When a package only provides static libraries you can place all the
files in the ''*-devel'' subpackage. When doing this you also have to
have a virtual Provide for the static package:
{{{
%package devel
Provides: foo-static = %{version}-%{release}
}}}
This way other packages which will link against a dynamic library when
your package starts providing one can {{{BuildRequire: foo-devel}}} and
packages which explicitly need to link against the static version can
{{{BuildRequire: foo-static}}}
=== Staticly Linking Executables ===
* Static linkage is a special exception and should be decided on a
case-by-case basis. The packager must provide rationale for linking
statically, including precedences where available, to FESCO for
approval.
-Toshio
16 years, 6 months
