packaging June 2007

packaging@lists.fedoraproject.org

33 participants
36 discussions

Re: "slicing" ocaml 3.10.0: comparison with debian friends?
by Richard Jones 15 Jun '07

15 Jun '07

On Thu, Jun 14, 2007 at 10:30:53PM +0100, Stefano Zacchiroli wrote: > Still, native code objects can break link time compatibility with > compatible .cmis. I don't understand - why is this? Rich. -- Richard Jones Red Hat

1 0

Re: "slicing" ocaml 3.10.0: comparison with debian friends?
by Richard Jones 14 Jun '07

14 Jun '07

On Thu, Jun 14, 2007 at 09:05:01PM +0100, Stefano Zacchiroli wrote: > On Thu, Jun 14, 2007 at 08:29:36PM +0100, Richard Jones wrote: > > We're actually distributing camlp4 as a separate package. To > > be honest I hadn't looked at the sizes until now: > > Thanks for this list! > > Would you mind sending us (maybe as an attachment?) a list of the files > contained in each package? From this list I can guess the content, but > just to be sure... Gemi did this actually. Here is the list of files: %files camlp4 %defattr(-,root,root,-) %dir %{_libdir}/ocaml/camlp4 %{_libdir}/ocaml/camlp4/*.cmi %{_libdir}/ocaml/camlp4/*.cma %{_libdir}/ocaml/camlp4/*.cmo %dir %{_libdir}/ocaml/camlp4/Camlp4Filters %{_libdir}/ocaml/camlp4/Camlp4Filters/*.cmi %{_libdir}/ocaml/camlp4/Camlp4Filters/*.cmo %dir %{_libdir}/ocaml/camlp4/Camlp4Parsers %{_libdir}/ocaml/camlp4/Camlp4Parsers/*.cmo %{_libdir}/ocaml/camlp4/Camlp4Parsers/*.cmi %dir %{_libdir}/ocaml/camlp4/Camlp4Printers %{_libdir}/ocaml/camlp4/Camlp4Printers/*.cmi %{_libdir}/ocaml/camlp4/Camlp4Printers/*.cmo %dir %{_libdir}/ocaml/camlp4/Camlp4Top %{_libdir}/ocaml/camlp4/Camlp4Top/*.cmi %{_libdir}/ocaml/camlp4/Camlp4Top/*.cmo %files camlp4-devel %defattr(-,root,root,-) %{_bindir}/camlp4* %{_bindir}/mkcamlp4 %{_libdir}/ocaml/camlp4/*.a %{_libdir}/ocaml/camlp4/*.cmxa %{_libdir}/ocaml/camlp4/*.cmx %{_libdir}/ocaml/camlp4/*.o %{_libdir}/ocaml/camlp4/Camlp4Filters/*.cmx %{_libdir}/ocaml/camlp4/Camlp4Filters/*.o %{_libdir}/ocaml/camlp4/Camlp4Parsers/*.cmx %{_libdir}/ocaml/camlp4/Camlp4Parsers/*.o %{_libdir}/ocaml/camlp4/Camlp4Printers/*.cmx %{_libdir}/ocaml/camlp4/Camlp4Printers/*.o %{_libdir}/ocaml/camlp4/Camlp4Top/*.cmx %{_libdir}/ocaml/camlp4/Camlp4Top/*.o %{_mandir}/man1/* > > $ rpm -q --requires ocaml-calendar > > I'll have a look at your guidelines. In the meantime, can you expand the > above command for non rpm speakers so that we can parse the output? :) It just lists the requirements (dependencies) of the ocaml-calendar package. For comparison, here are symbols provided by the same: $ rpm -q --provides ocaml-calendar ocaml(Calendar) = db8ca9a52d58e744b63d354d36f12620 ocaml(Date) = 57886756cbdb3aa1db37638a7809f610 ocaml(Period) = e220d29e5b87b6ec8b8b474a2ae54685 ocaml(Printer) = 4454f0bfed349268f57ffd82a7d78499 ocaml(Time) = 35fe4ca99bb3640b22bc286fc97adff5 ocaml(Time_Zone) = 23b711a8eb543e69e6f53d67a0eccf57 ocaml-calendar = 1.10-5 The symbols are generated automagically by scanning the OCaml objects (*.cmi, *.cmo, *.cma) using ocamlobjinfo. The two scripts attached to this bugzilla do it: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004 (scroll down to near the bottom). Rich. -- Richard Jones Red Hat

1 0

Re: "slicing" ocaml 3.10.0: comparison with debian friends?
by Richard Jones 14 Jun '07

14 Jun '07

On Thu, Jun 14, 2007 at 08:02:01PM +0100, Stefano Zacchiroli wrote: > Hi Richard, > in Debian we are almost ready to upload an official version of the > ocaml 3.10.0 packaging [1], I know from the caml mailing list that > you're working on similar stuff for red hat derivatives. > > One of our remaining concern is that the ocaml-nox package is more than > 100 Mb of installed size. About 70 Mb of that are devoted to camlp4 > executables and libraries, hence we are considering splitting that to a > separate package. > > Have you had similar concerns? If so, which kind of splitting you > decided to perform? I'll be glad to share opinions with you guys on > that! We're actually distributing camlp4 as a separate package. To be honest I hadn't looked at the sizes until now: 5.7M ocaml-3.10.0-2.x86_64.rpm 22M ocaml-camlp4-3.10.0-2.x86_64.rpm 7.1M ocaml-camlp4-devel-3.10.0-2.x86_64.rpm 3.6M ocaml-debuginfo-3.10.0-2.x86_64.rpm 2.1M ocaml-docs-3.10.0-2.x86_64.rpm 87K ocaml-emacs-3.10.0-2.x86_64.rpm 362K ocaml-findlib-1.1.2pl1-5.x86_64.rpm 130K ocaml-findlib-devel-1.1.2pl1-5.x86_64.rpm 388K ocaml-labltk-3.10.0-2.x86_64.rpm 1.8M ocaml-labltk-devel-3.10.0-2.x86_64.rpm 2.4M ocaml-ocamldoc-3.10.0-2.x86_64.rpm 1.5M ocaml-runtime-3.10.0-2.x86_64.rpm 77K ocaml-source-3.10.0-2.x86_64.rpm 20K ocaml-x11-3.10.0-2.x86_64.rpm Those sizes are, of course, compressed. camlp4 is pretty huge, isn't it. > PS similarly, I know you prepared the red hat derivatives guidelines for > packaging OCaml stuff and that you started from our policy. Feel free to > post suggestions for / improvements to our policy to our mailing list. > > [1] if you're interested in what we are doing you can find it at: > http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/ocaml/branches/oc… I'm very much following Debian's policy and packages to see what you've done and how you've done it. Fedora policy: http://fedoraproject.org/wiki/PackagingDrafts/OCaml Despite the name, this has just been approved. You might be particularly interested in the very strict versioning scheme that Fedora adopted. For example: $ rpm -q --requires ocaml-calendar [...] ocaml(Array) = aa8e3cd5824f9bb40b93fcd38d0c95b5 ocaml(Buffer) = f6cef633ea14963b84b79c4095c63dc3 ocaml(Format) = 35fe566f7a37d8991a5c822bd1463949 ocaml(Lazy) = 8a4b5e7f0bdc6316df9264fd73cde981 ocaml(List) = da1ce9168f0408ff26158af757456948 ocaml(Pervasives) = 8ba3d1faa24d659525c9025f41fd0c57 ocaml(Str) = 56bb7ee61b2da83d42394686e3558fe4 ocaml(String) = 2c162ab314b2f0a2cfd22d471b2e21ab ocaml(Unix) = 9a46a8db115947409e54686ada118599 ocaml = 3.10.0-2 And I do have a question actually ... Why does Debian put version numbers into the paths (eg. /usr/lib/ocaml/3.09.3/...)? In Fedora we don't do this. The advantage of putting version numbers in there is it would allow us to install multiple versions at the same time, but we'd have to go all the way down to the -release level to make this realistic, _and_ we'd have to version everything in /usr/bin as well. I'm wondering if Debian have some deep insight that I'm missing. Rich. -- Richard Jones Red Hat

1 0

multilib and concurrent virtual arch-less provides
by Axel Thimm 13 Jun '07

13 Jun '07

Hi, I encountered the following: Dependencies on perl(Foo) virtual provides can be offered by i386 and x86_64 packages. If these packages have been tagged as multilibbable then the x86_64 repo has two different packages offering the same virtual provides. This means that installing by dependencies, BuildRequires: or Requires: may be satisfied by the wrong package, or in the best case by two packages confusing the depsolver. More precisely I hit this with perl(ExtUtils::MakeMaker) in an emtpy chroot. -- Axel.Thimm at ATrpms.net

1 0

Missing today's meeting
by Jesse Keating 12 Jun '07

12 Jun '07

I have something else taking me away from this time slot today. Apologies. -- Jesse Keating Release Engineer: Fedora

1 0

OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)
by Richard W.M. Jones 11 Jun '07

11 Jun '07

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/775714fbf05c17e0cbf5… 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

3 16

Game binaries under /usr/games/?
by Matthias Saou 11 Jun '07

11 Jun '07

Hi, I've now got 3 pending bugs against 3 different games, because it seems that prelink and selinux don't mix well with binaries installed under /usr/games. (*) I recall having looked at the FHS when initially packaging these games, and having left them install their binaries in /usr/games/ since it was the default behaviour, and I wanted to stick as much as possible to upstream. I read the Games SIG packaging recommendations : http://fedoraproject.org/wiki/SIGs/Games There is a mention of _not_ using /usr/share/games/ and putting stuff under /usr/share/ directly, but no mention of binaries in /usr/games/. Should we consider it "wrong"? Should the default selinux policy be updated? Matthias (*) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218280 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229197 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243031 -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.43 0.43 0.53

3 2

Status of OCaml packaging
by Richard W.M. Jones 11 Jun '07

11 Jun '07

Some brief notes on what has happened since last Tuesday w.r.t. OCaml packaging in Fedora. Gerard produced the base ocaml package for OCaml 3.10.0 (the latest upstream version). OCaml 3.10 has some major changes which affect a lot of upstream packages. https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01397.html https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004#c13 http://caml.inria.fr/ocaml/release.en.html After last Tuesday's meeting I've fixed several things which were problems: * I've built all but two OCaml packages against OCaml 3.10, including submitting an upstream patch. The two which don't yet work are ocaml-pxp and cduce, which both require significant effort upstream. (http://annexia.org/tmp/ocaml/, http://tinyurl.com/2rl4w6) * rpmbuild now doesn't call rpm recursively. * OCaml dependencies now look like ocaml(ModuleName) = Hash * ocaml-find-requires and ocaml-find-provides scripts are looking more solid and final, and are working their way into RPM. (https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01071.html) * I fixed the way that we split out the -devel subpackage (I think). (https://www.redhat.com/archives/fedora-packaging/2007-June/msg00064.html) * All packages now support bytecode architectures. I've revised the OCaml Packaging Draft guidelines several times. The latest version is here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml 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

1 0

pre-install and post install instructions in a rpm
by lostson 10 Jun '07

10 Jun '07

Hello all I am trying to package up obconf 2.0 with the new openbox 3.4 and am having troubles. With obconf upon install and uninstall I need to run these two commands. update-mime-database /usr/share/mime update-desktop-database /usr/share/applications I was reading some documentation that was talking about possibly using shell scripts to issue those commands both on install and uninstall. Is this the correct procedure or is there a more efficient way, thanks. -- LostSon http://www.lostsonsvault.org

2 1

License text
by Jason L Tibbitts III 07 Jun '07

07 Jun '07

The Review Guidelines state: - MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. but this rule is not actually in the packaging guidelines. In fact, there are various bits which exist in the review document that aren't mentioned in the guidelines themselves. I guess we should make an effort to make sure that all of these are dealt with, but one thing at a time. So, here's a proposal. I'll draft it in the wiki if folks would prefer that, but as this isn't actually a change of the guidelines as a whole (since they include the review guidelines) I think we can just do a quick vote and if there's no controversy then just make the change and notify fesco. Proposal: Amend the Licensing section of the Guidelines. Immediately previous to the Shareware subsection, add the following subsection: ---------- === License Text === If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included as documentation. ---------- - J<

8 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2007