Re: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)
by Richard W.M. Jones
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
16 years, 10 months
Re: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)
by Richard W.M. Jones
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
16 years, 10 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, 10 months
Missing today's meeting
by David Lutterkort
Unfortunately, I won't be able to come to today's FPC meeting.
sorry about that,
David
16 years, 10 months
RFC: Signed JAR Packaging Policy
by Rex Dieter
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.
16 years, 10 months
Requires: initscripts?
by Matthias Saou
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
16 years, 10 months
Upgrading databases as part of the RPM postinst script?
by Maxim Veksler
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 ?
16 years, 10 months
Pulling with bzr to create source tarballs.
by Jef Spaleta
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
16 years, 11 months
Cross-compiling guidelines
by Kevin Kofler
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
16 years, 11 months