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
First user/group handling discussion draft
by Ville Skyttä
Hello,
The first draft about user and group handling (creation etc) is ready for
discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
The draft was presented in yesterday's FPC meeting, but the quick conclusion
was that it'd be better to discuss it on list first. The draft currently
contains only an implementation of the all-dynamic uid/gid mapping scheme -
more may follow later if the consensus is that other schemes are actually
required in packages (ie. not adequately addressable outside of them).
16 years, 6 months
missing tomorrow's FPC meeting
by Ralf Corsepius
Hi,
Due to a public holiday in Germany, I'll be AFK most of the day and
therefore probably will not be able to attend the FPC meeting.
No matter if it will take place at 17:00 or 16:00 UTC ;)
Ralf
16 years, 7 months
Using %global instead of %define in conditionalized macro expressions
by Axel Thimm
Or to place it more explicit make
%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
%{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")}
[%{!?foo: %define foo ...}]
to
%{!?python_sitelib:%global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
%{!?python_sitearch:%global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")}
[%{!?foo:%global foo ...}]
Otherwise using parametrized macros can mess things up (#237448). The
nesting levels seems to get mixed up and the conditionalized
definition above get swallowed away. The %global ensures that this
bug doesn't happen.
It may also be cleaner to remove the space between the colon and the
percent sign.
--
Axel.Thimm at ATrpms.net
16 years, 7 months
satic libs package naming
by Patrice Dumas
Hello,
In the guidelines it is said that static libs subpackages should be
called *-static. This triggers lots of rpmlint warnings so I currently
use (and propose in reviews) *-static-devel. Should I revert to *-static?
If *-static-devel is acceptable, maybe it could be said so in the
guidelines.
Also, unless I am wrong on that point, maybe in the guidelines there could
be a note that when there is only static libraries there is no need of
static subpackage and the static libs may be in -devel.
--
Pat
16 years, 7 months
Using of date in snapshot versions
by Till Maas
Hiyas,
the naming guidelines say that one should use the date do describe the
snapshot:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-cfd71146dbb...
| If a snapshot package is considered a "pre-release package", you should
| follow the guidelines listed in Pre-Release Packages, and use an %{alphatag}
| in the following format:
| YYYYMMDDcvs
Maybe this is useful for cvs, because there is no better way to describe a
snapshot. But e.g. with svn, which uses a global revision number, it is
possible to use a unique id for the snapshot, where it is not uncertain which
changes are included. For this reason I suggest to change the guideline, so
that it suggests better identification strings for a snapshot, when it is
avaiable, e.g.
123svn
for a snapshot of an svn repository at revision 123.
Regards,
Till
16 years, 7 months
Issues with Ocaml and Static Linking
by Nigel Jones
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGHZpipldg9bRmG6kRAk8IAJ9JepuGRc7m3AH35XFhRUKG+w1xYgCgis+F
BhyetHeiFfS5U9svDsy9Ufc=
=RmdN
-----END PGP SIGNATURE-----
16 years, 7 months
