Packaging:Minutes20070605

From FedoraProject

Jump to: navigation, search

Contents

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

Present

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

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.
Retrieved from "https://fedoraproject.org/wiki/Packaging:Minutes20070605"