Packaging:Minutes20070605

Fedora Packaging Committee Meeting of {2007-06-05}

Present

• JasonTibbitts (tibbs)
• RalfCorsepius (racor)
• RexDieter (rdieter)
• VilleSkyttä (scop)

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