Packaging:Minutes20070605

Present

 * JasonTibbitts
 * RalfCorsepius
 * RexDieter
 * VilleSkyttä

(No quorum this week.)

Writeups
No proposals were submitted to FESCo last week.

Votes
No proposals were voted upon this week.

Other Discussions
The following additional items were discussed; see the logs for full details.


 * OCaml guidelines: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
 * These are nearly done now.

IRC Logs
[12:02] So, FPC meeting? [12:02] * rwmjones is here to help with ocaml [12:02] no spot,abadger today... [12:03] Yes, unfortunately we're missing some folks and I am going to have to run in and out a few times. [12:04] any comments on XChat/desktop thread? https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02138.html [12:04] same for me, I am here, but I am on and off, and will have to leave early [12:05] --> scop has joined this channel (n=scop@cs181043142.pp.htv.fi). [12:05] and https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01198.html [12:05] imo, Kevin had a point. [12:06] which was precisely my motivation for putting the wording into the Guidelines about  Name=, GenericName=, ... [12:06] Well, I thought the definitions of Name and GenericName were pretty clear, but it seems the desktop group doesn't agree and I'm still not sure why. [12:07] I can understand their pov, but their implementation choice of abusing the spec was bad. [12:08] So we have enough folks here to vote? We owe the ocaml folks some consideration. [12:08] I count 3, so prolly not. [12:08] f13? [12:08] four with scop here. [12:09] *** rdieter sets the channel topic to "Fedora Packaging Comittee meeting - http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel". [12:09] I'm fine with going over the packaging guidelines to see if there's anything wrong -- can spend the next week fixing them up [12:09]  http://fedoraproject.org/wiki/PackagingDrafts/OCaml [12:10] also I have an ever-growing list of packages, here: http://tinyurl.com/2rl4w6 [12:10] as long as ocaml-find-requires.sh/provides doesn't use rpm queries... :) [12:11] yeah, I need to fix that one [12:11]  I wonder what it would take to get rid if the _use_internal_dependency_generator bits and have the ocaml-find-*.sh scripts be called like the perl ones. [12:12]  * rwmjones doesn't know how to do that [12:13]  Looks like they're hardcoded in the find-provides script.  Kind of suboptimal, I guess. [12:13]  tibbs: good question, not using internal_dep_generator is prolly not ideal. [12:13]  I thought that '%define _use_internal_dependency_generator 0' was necessary so that RPM would use the %define __find_provides/requires at all.  Othewise it seems to ignore them. [12:13]  s/RPM/rpmbuild/ [12:13]  Yes, but the point is that we should get the dependency finding hooked up by defailt, as Perl, Python and Tcl are. [12:13]  rwmjones: you're right, it's just that the internal_*_generator is better at some things. [12:13]  hm, ocaml-Modulename-MD5hash [12:14] looks inconsistent with other languages for which we have perl(Foo::Bar), ruby(foo) etc [12:14] scop, you end up with requires which look like this: [12:14] # rpm -q --requires ocaml-calendar [12:14] rpmlib(PayloadFilesHavePrefix) <= 4.0-1 [12:14] rpmlib(CompressedFileNames) <= 3.0.4-1 [12:14] ocaml-Array-a904b798dd9665c2d3635636d293403c [12:14] ocaml-Buffer-45f466ce46f213dae41be77dd8505f5f [12:14] ocaml-Format-67f81fa527012cf0f70f6f6a24f07417 [12:14] ocaml-Lazy-27baa9469b2986a6ccbba3e85275ecf1 [12:14] ocaml-List-5a0e3217fc356bd18f60bff31861dfd3 [12:14] ocaml-Pervasives-71f888453b0f26895819460a72f07493 [12:14] ocaml-Str-8a11c5ef144a995903cc9e1bac5e353c [12:14] ocaml-String-fec8292bb1a02d2c7b8b4ba7b83a7d8b [12:14] ocaml-Unix-1876ce678cfa5a1961fac21850f71efd [12:15] ocaml = 3.09.3-2.fc6 [12:15] note that these are necessary because OCaml has very strict module dependencies, it's not at all like dynamic languages [12:15] I understand the idea [12:15] I think the point is that these should be something like ocaml(module-hash). [12:15] ok, I see - that shouldn't be a problem [12:15] ocaml(module-hash) or ocaml(module,hash)? [12:15] right, that would look more like what other languages have [12:16] Is the hash akin to a version? [12:16] tibbs: looks like it, kinda sorta. [12:16] it's a hash of the signature and some internals [12:16] are these cryptic strings in ocaml-XXX-... versions? [12:16] perhaps Provides: ocaml(module) = hash [12:16] tibbs: +1 [12:16] the ocaml linker uses these hashes too to decide if modules are compatible [12:17] if we use '=' does that imply some sort of ordering? the hashes don't have an ordering [12:17] There's no ordering, but it seems that all of the dependencies are going to require strict equality. [12:17] rwmjones: so, are they are ids or version? [12:17] racor, not sure I understand that question, sorry [12:18] your example contains strings like  ocaml-Buffer-45f466ce46f213dae41be77dd8505f5f [12:18] They encode a version, but they provide no specific ordering. [12:18] they are MD5 hashes over the signature & internals of the module [12:18] signature == interface [12:18] my question would be: is the 45f466ce46f213dae41be77dd8505f5f a version, ie. steadily increasing or an id (ie. unique but without order) [12:18] fwiw, see also rpm -q --provides kernel | grep -F 'kernel(' [12:18]  no, they definitely don't increase [12:19]  no ordering [12:19]  then you're in trouble ... [12:19]  scop, yes, they are just like those kernel deps [12:19]  you said, they need to match [12:20]  I don't see why there's any trouble. [12:20]  these seem to be strictly virtual Requires/Provides, and not any real package, so it shouldn't matter. [12:20]  but a valid concern to be aware of. [12:20]  so the module (eg. Array) is part of base ocaml in that example [12:20] tibbs: how would you want to upgrade from o-x-123 to o-x-abc [12:20]  # rpm -q --provides ocaml-calendar [12:20]  ocaml-Calendar-514a56b1c3e9c1e5139e81e0e2736ab8 [12:20]  ocaml-Date-0b9d8d46ec722919ef4a2b4f7576d8f1 [12:20]  ocaml-Period-d99e051c4c63bb80cd2586ea99584429 [12:20]  ocaml-Printer-de9afc53dc6db958fdf5927dc86df9aa [12:20]  ocaml-Time-1b657b86bb0e7ba36acf02910897b2eb [12:20]  ocaml-Time_Zone-8d84727c6f398e1a8b710d8161e26479 [12:20]  ocaml-calendar = 1.10-3 [12:21]  racor: I don't see why that is a consideration, sorry. [12:21]  scop: Why do I not see those virtual kernel provides? [12:21]  racor: no upgrades, just to get strict runtime dependencies satisfied. [12:21]  tibbs, which distro version? [12:21]  scop: rawhide. [12:22]  tibbs: When using them in requires/provides you're in trouble [12:22]  dunno, I see them on FC6 [12:22]  racor: I fail to see the trouble. [12:22] but not on F7 [12:22]  racor: true, it is kinda abusing Version, but I don't see the harm here. [12:22] weird [12:23] Ah, yes, those kernel provides follow the ocaml model precisely. [12:23] The version is even a hash of the interface. [12:23] rwmjones: as long as there is no chance of any real package ever being named, e.g., ocaml-Date, but that be avoided by using the suggested ocaml(Date) approach. [12:24] package X version N will provide o-X-123, package Y will require o-X-123, now package X is updated to N+1 which provides o-X-abc, o-X-123 will vanish and Requires: o-X-123 wil not be satisfied [12:24] That's precisely the issue that ocaml is facing. [12:24] racor, yes, you can only upgrade ocaml libraries all at once [12:24] racor: we're trying to advocate using Requires/Provides: ocaml(module) = hash instead of  Requires/Provides: ocaml-module = hash [12:25] rwmjones: +1. racor, yeah it sucks, but we're stuck with how ocaml works. [12:25] rdieter: I have no clue about ocaml, I want to understand which of these provides/requires are useful and which are not [12:26] ATM, these are not clear to me [12:26]  racor: I haven't much a clue either, I'm taking rwmjones' word on it that ocaml has *very* strict runtime deps. [12:26] racor, so a hypothetical library which needs ocaml-calendar's Calendar and Date would require precise versions of them (the ones it was compiled against) [12:26] and the ocaml linker checks the hash of each [12:26] when linking the whole program [12:27] what about toplevel or ocaml scripts? [12:27] they may require some "modules", but no version in particular? [12:27] those are different, because they are compiled when they are run [12:27] rwmjones: My conclusion from this: ocaml(X) would be useless [12:27] or should be ocaml(X) = 12344 [12:27] but then ocaml-X-12344 would be redundant [12:28] racor: the latter, exactly, that's what we've been advocating! :) [12:28] ocaml(module) = hash [12:28]  I think ocaml(X)=hash makes total sense [12:28]  & if people agree, I'll change that [12:28]  rwmjones, so scripts etcthey might actually have use for let's say ocaml(Date) (without the hash) [12:28]  s/etcthey/etc/ [12:28]  scop, it's a good question - yes, maybe, but they still might fail if incompatible changes have been made [12:28]  anyway, there are hardly any ocaml scripts [12:29]  rwmjones: Are these requires/provides automatically generated? [12:29]  yes, by: [12:29]  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004 [12:29]  the scripts attached to the ^^ bug [12:29]  rwmjones, sure, but having it in the Provides on the right of "=" would satisfy those too [12:29]  comment 5 is the interesting one [12:30]  my point is that if it's attached to the name of the Provides, they couldn't use it [12:30]  scop, yes [12:31]  scop, I think you're saying: a hypothetical ocaml script could require ocaml(Date) (without any hash)? Yes, this could happen, but the script might still fail to run if changes had been made to Date - eg. if a function had a different number of arguments [12:32] rwmjones, of course [12:32] in that case there's not much else to do except to require (versioned) a main package or something [12:32] So, a different question: what's the %opt bit? [12:33] Are there fedora-supported platforms which don't have ocamlopt? [12:33] anyway, just thinking aloud, I think ocaml(foo) = hash is fine [12:33] tibbs: ok, so ocamlopt is the native compiler for ocaml, but it's not been ported to all platforms that Fedora supports (eg. ppc64) [12:33] tibbs, http://fedoraproject.org/wiki/PackagingDrafts/OCaml#head-14a9d22bff07b51f58d01bb4e79bcbe98e426a7c [12:34] so on ppc64, we only get the bytecode compiler which is slower but still useful. So spec files need to run on full platforms and bytecode-only platforms [12:34] cute. [12:34] I guess it beats an ExcludeArch:. [12:35] with any luck ExcludeArch shouldn't be needed at all, because the bytecode compiler & interpreter runs everywhere [12:36] good. update the draft, and I'll venture we would likely vote positively on this next week. [12:37] ok, I've got 3 things then: don't call RPM recursively, ocaml(Module)=hash, look at integrating find-provides and find-requires with the internal dep generator. [12:37] that last one, don't worry too much about. [12:38] unless someone comes up with something clever in the meantime. [12:38] thanks for your help everyone [12:38] Well, we can ask for those bits to be added. [12:38] Ideally we could get rpm to run through the find-whatever scripts in a directory. [12:38] tibbs: +1 [12:39] comments about http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippetsFixes ? [12:41] looks good. [12:42] Yes, that looks fine to me. [12:43] the more I think about it, since failed scriptlets pretty reliably borks rpm/database/transactions, wouldn't it make sense to push to make scriptlet failures non-fatal in rpm? [12:44] could very well be [12:44]  I guess it would always be nice if bogus rpm bits were fixed, but I guess all we can do is hope. [12:46] anything else today? [12:47] nothing here. [12:48] I didn't have enough time to draft the "don't screw with the tarball more than you have to" draft. [12:48] I think that about sums it up. :) [12:49] and if you have to ask, then you're doing too much. [12:49]  ok, let's call it then.