packaging May 2007

packaging@lists.fedoraproject.org

32 participants
22 discussions

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

21 May '07

David Woodhouse wrote: > On Mon, 2007-05-21 at 12:00 +0100, Richard W.M. Jones wrote: >> Now, a bit of background first. When OCaml builds a module, it takes a >> MD5 hash over the interface and some of the internals. It also stores >> in the module the MD5 hashes of any modules that it depends upon. At >> link time the MD5 hashes are compared, and the link is only allowed to >> proceed if they match. > > Hm. Can we use this to make dynamic linking work safely too? If you mean Dynlink (the bytecode-only dynamic linker), then that uses the same hashing scheme and has the same requirements (matching hashes, matching compiler). So yes. 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

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

21 May '07

David Woodhouse wrote: > On Sat, 2007-05-19 at 17:36 +0100, Richard W.M. Jones wrote: >> 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. > > Our current package scheme doesn't handle this at all, does it? Should > our ocaml-*-devel packages have runtime Requires: on the precise n-v-r > of ocaml used to build them? Yes definitely. In fact any other behaviour is broken. (All packages should have this Requires -- I'm not sure why you elected for just the -devel packages). Furthermore, if one library or program depends on another library, then it must contain a dependency on the precise n-v-r of the library. The only reason I didn't do it for the four packages I just put up for review is that I couldn't work out _how_ to do it in the spec file :-( [My packages for review: http://tinyurl.com/2rl4w6] Example: ocaml-3.09.3-1 ocaml-pcre-5.11.4-1 Requires: ocaml = 3.09.3-1 ocaml-extlib-1.5-1 Requires: ocaml = 3.09.3-1 cocanwiki-1.4.3-1 Requires: ocaml-pcre = 5.11.4-1, ocaml-extlib = 1.5-1, ocaml = 3.09.3-1 The final package requires the precise versions of the two libraries it was built against, plus the precise version of OCaml that it was built with. I don't know how well this will interact with the Fedora build system. For instance if a new version of a fairly fundamental library (eg. ocaml itself, or something like ocaml-pcre) is released, everything which depends on that has to be recompiled. This is something of a perpetual problem for the Debian folks. At one point I remember that OCaml in Ubuntu was really broken, apparently because they'd taken packages from upstream Debian half way through a transition like this, so some packages were compiled against one version of ocaml-pcre, and others against another version, with the result that you couldn't use certain combinations of libraries if the libraries depended on different ocaml-pcre. 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 1

First user/group handling discussion draft
by Ville Skyttä 15 May '07

15 May '07

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).

7 38

Missing today's meeting
by David Lutterkort 15 May '07

15 May '07

Unfortunately, I won't be able to come to today's FPC meeting. sorry about that, David

3 2

RFC: Signed JAR Packaging Policy
by Rex Dieter 15 May '07

15 May '07

Per RFC: Signed JAR Packaging Policy http://lwn.net/Articles/225981/ Review Request: jss - Java Security Services (JSS), http://bugzilla.redhat.com/230262 The "jar signing issue" is something we'll have to address somehow sooner or later. Imo, it can/should be considered on the same level as Fedora's signed rpms. <crazy_idea> Maybe fedora could have some sort of fedora-ca-keys pkg containing java CA's that's *only* available to the buildsys (ie, private, similar to fedora's rpm keys). We could also provide some sort of dummy fedora-ca-keys pkg in our public repos (or some other means for folks to generate/create their own ca-keys-containing pkg) to satisfy the reproducibility(*) issue. </crazy_idea> comments? -- Rex (*) reproducible in that you could build signed jars, but they wouldn't be identical, obviously.

2 7

Requires: initscripts?
by Matthias Saou 11 May '07

11 May '07

Hi, I've never added "Requires: initscripts" to packages which contain an init script before. I've now been asked to in this review : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233455 I like to avoid as many explicit requirements as possible, and in this particular case, the "require packages owning parent directories of our files and directories" of recent rpm versions (unfortunately not in Fedora, though IIRC) would take care of things. So my question : As long as the Requires(...) for the scriplets are fine in order to get the package properly installed, updated and erased, do we still need to add that explicit requirement? I would say we don't, but I prefer asking to be sure... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.34 0.48 0.47

8 25

Upgrading databases as part of the RPM postinst script?
by Maxim Veksler 09 May '07

09 May '07

Hi list, As part of the software (binaries) upgrade process my rpm will need to update database scheme (and possibly some configurations data) inside a mysql database. Are there any recommendations or case studies I should follow to screw things up as little as possible ? Thanks and happy hacking, Maxim. -- Cheers, Maxim Veksler "Free as in Freedom" - Do u GNU ?

6 7

Pulling with bzr to create source tarballs.
by Jef Spaleta 04 May '07

04 May '07

Good Morning Campers, It appears that pulling from bzr to produce a source tarball can not be done in a way that preserves file timestamps. This makes it impossible to easily verify the md5sum of a tarball created this way. The review guidance implies that that a comment block in the spec file needs to provide enough information to recreate and verify such a tarball. Unfortunately for bzr, the verification of the tarball will always fail due to the timestamp issue. As a workaround, i suggest that for tarballs built from a bzr export that the spec file include a note that the contents of the tarball must be verified individually, and that a note concerning bzr's inability to preserve timestamps (and the dire consequences of that) be added to the code control related review guidance. For reference see the discussion in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235191 I have manually verified that the contents of the included source1 tarball match the files pulled from call to bzr in the specfile comment block. and for bzr's plan for timestamps: https://blueprints.launchpad.net/bzr/+spec/export-original-timestamps -jef"why am i not drinking tequila right now?"spaleta

1 0

Cross-compiling guidelines
by Kevin Kofler 03 May '07

03 May '07

There are at least 2 review requests for cross compilers which have been stuck in FE-GUIDELINES for over a year (to the point where the submitter closed the reports) supposedly waiting for specific guidelines for cross-compiling, so I wonder what happened to those guidelines. Is there any chance some guidelines are going to be voted by the packaging committee or some SIG or both at some point? Or is the consensus now that none are needed? In the first case, I'd like to see something getting done about this sooner rather than later, as I think we lose on useful packages by holding them up forever (and admittedly, I also have an interest in this), in the second case (no guidelines needed) I'll just put the bugs out of FE-GUIDELINES and review them according to the general packaging guidelines and the things interested parties agreed upon on the fedora-extras-list a few months ago. Kevin Kofler

5 7

http://fedoraproject.org/wiki/Packaging/NewMeetingTime
by Tom Callaway 01 May '07

01 May '07

FPC members: Please go to http://fedoraproject.org/wiki/Packaging/NewMeetingTime and put in times which will work for you to attend. I've also put in the other times which are already taken in #fedora-meeting, so that we don't accidentally choose a time which is already in use. Thanks in advance, ~spot

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging May 2007