On Wed, 2007-05-30 at 15:14 +0100, Richard W.M. Jones wrote: > Toshio Kuratomi wrote: > > Thanks, those scripts look good. > > So what's the next step? I've added (or in two cases, changed) 14 OCaml > packages which are waiting for another person to review them. You can > get the full list of Bugzillas through this link: > > http://tinyurl.com/2rl4w6 > If you, Gérard, Hans, and the other people working on OCaml think the guidelines are ready we can discuss and vote to include them at next week's packaging meeting. The committee is meeting at Tuesday at 17:00 UTC for about an hour in #fedora-meeting on freenode IRC. If any of you can make it to the meeting that would be great as it helps to have someone familiar with the language there to field any questions that may come up. > I understand that everyone's really busy getting F7 out of the door, and > also that OCaml doesn't interest many people. But anyway to kick things > off, here are some of the things which I think could be problems: > > (1) Because of the strict dependencies, users could only upgrade ocaml + > all OCaml libraries they are using in one go. > > (2) Also as a consequence of (1), if a major release of OCaml comes out, > all OCaml libraries have to be upgraded at the same time. If, for > example, we move to 3.10, then all libraries upstream must support 3.10. > > --> Possible solution to (1) & (2): Put the version number in > the library path, as Debian does. This may allow multiple versions > to coexist. > > --> Upstream support (2) is not much of a problem in reality. > Other packages like this (python, perl, ruby) do have versioned subdirectories so that might be the best way to go. Do upstream build scripts generally make this easy to do? > (3) OCaml contains a native code compiler, but that compiler hasn't been > ported to all architectures that Fedora supports. It has a bytecode > compiler which works everywhere (but is interpreted and hence slow). I > haven't been very careful about detecting if native code is supported on > the current architecture. > > --> ExcludeArch and/or lots of nasty %ifarch sections in %files. > > --> I don't have a non-native arch to test on. > What's missing? ppc64? Is there a possibility of support being added upstream? I can't think of any other packages/languages that have this problem offhand. We may need to do something nasty with subpackages and %ifarch but I'd rather avoid that if possible. I don't know how possible that is, though. > (4) rpmlint gives a few familiar warnings: > > devel-file-in-non-devel-package (about *.cmi files) > > --> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241471 > Looks like this one is being worked on. > only-non-binary-in-usr-lib > > --> A consequence of the above. > > unstripped-binary-or-object > > --> You can't strip OCaml bytecode binaries because the bytecode > gets stripped too. Arguably that's an upstream bug. > > no-binary > > --> Packages which contain no binaries should be in noarch - > fair enough, but I don't know how to do this in the spec file > and keep the subpackages arch-specific. > Yeah -- if one package/subpackage is arch specific then all of the pieces built from it have to be. > configure-without-libdir-spec > > --> The ./configure scripts are often written in OCaml and don't > use the standard autoconf options. > Okay. So this looks like rpmlint sees ./configure as an autoconf configure script when it really is not. > (5) How does the Fedora build system work? To build a library you need > to have the OCaml compiler and all dependent libraries installed > (enforced through BuildRequires) and you'll get out an RPM which only > installs with the precise compiler and library which were installed when > it was compiled. So the only sequence that works is: > # remove all ocaml RPMs > $ rpmbuild -ba ocaml.spec > # install ocaml RPM > $ rpmbuild -ba ocaml-lib1.spec > # install ocaml lib1 RPM > $ rpmbuild -ba ocaml-lib2.spec > # install ocaml lib2 RPM > etc. > Every build is a fresh mock buildroot. It includes the packages in the minimal install plus BuildRequires and their dependencies. The packages are drawn from the current download repository plus the packages that have been built recently but not yet made it to the repository. With the new koji builders (for F7) you have to tell it to do a chainbuild to guarantee that the recently built package is included in the new build. Until a better UI is worked out, here's a post on how to do that: http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01850.html I think that will take care of getting new versions of OCaml through the build system. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
