Meeting:Packaging IRC log 20070102

(09:08:21 AM) The topic for #fedora-packaging is: Channel for Fedora packaging related discussion | Next Meeting: Tuesday, January 2nd, 2007 17:00 UTC (09:08:47 AM) tibbs: Well, there's one more. (09:08:49 AM) scop [n=scop@cs27014175.pp.htv.fi] entered the room. (09:08:57 AM) tibbs: And another. (09:09:04 AM) scop: hi (09:09:08 AM) abadger1999: Hello (09:09:19 AM) tibbs: That's five when spot finishes his phone call. (09:21:04 AM) spot: sorry guys, still on this call (09:21:10 AM) spot: hooray for eager users (09:22:56 AM) ***scop needs to go in about 15 minutes (09:23:17 AM) XulChris: can we quickly discuss php additions to packaging guidelines? (09:23:23 AM) XulChris: please (09:24:11 AM) tibbs: What's the URL of the draft proposal? (09:24:38 AM) RemiFedora: i've not post it on the wiki, but only on the ML (09:24:46 AM) RemiFedora: https://www.redhat.com/archives/fedora-packaging/2006-December/msg00124.html (09:24:53 AM) RemiFedora: https://www.redhat.com/archives/fedora-packaging/2006-December/msg00188.html (09:26:40 AM) RemiFedora: i probably should have updated the PackagingDrafts/PHP page (09:26:41 AM) scop: "no file in BUILD directory": I think that's nothing specific to PHP packages, no packages should extract anything directly there (09:27:25 AM) tibbs: Still, all PHP packages will have that errant file, so it doesn't really hurt to mention it there. (09:27:55 AM) scop: sure, but we should check that it is mentioned somewhere more "generic" in addition (09:28:08 AM) tibbs: Are the rpmdevtools and php-pear-PEAR-Command-Packaging templates the same? (09:28:42 AM) RemiFedora: nearly. rpmdevtools must be filed, php-pear-PEAR-Command-Packaging is automatic. (09:29:25 AM) tibbs: That makes sense; it's like the perl template and cpanspec, which fills in the template. (09:29:42 AM) scop: FWIW, I don't like the "php_zend_api" or "php-abi" naming (09:29:54 AM) tibbs: It's not for us to choose, however. (09:29:58 AM) scop: it's different from everything else (09:30:19 AM) ***spot is off his call (09:30:21 AM) scop: php(abi), php-zend(api) would be better, see python and ruby (09:30:27 AM) tibbs: I have no idea why they were chosen to be underscores. We weren't consulted about that. (09:30:34 AM) spot: +1 on scop's comment (09:30:45 AM) tibbs: Still, it's an F7-only thing, so it could be changed with no impact. (09:31:13 AM) tibbs: Anyone with a direct line to Joe Orton to ask why he chose those names? (09:31:34 AM) RemiFedora: there's a little mistake, it's Requires: php-zend-api = %{php_zend_api} (09:32:30 AM) abadger1999: scop: +1 (09:32:51 AM) tibbs: Well, that's a bit better, but the parenthesized bits seem to be more in line with how other packages work. (09:33:02 AM) spot: RemiFedora: can you work with Joe on possibly renaming the macros to match the existing guidelines? (09:33:05 AM) lutter: I think (1) and (2) are fine to stick into the guidelines as 'tips for packagers' .. we should really have more of those (09:33:51 AM) RemiFedora: Bug still open : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212804 (09:34:06 AM) abadger1999: RemiFedora: > Requires: php-api could be keep, but is not very useful (09:34:13 AM) abadger1999: Where does php-api come from then? (09:34:13 AM) spot: lutter: yeah, i think (1) and (2) fall under "good common sense", i don't see a problem with adopting them into the php guidelines (09:34:38 AM) tibbs: It was there in the PHP package when we started writing guidelines, so that's what we had to use. (09:35:27 AM) scop: could we go through the AI status quickly before I need to go? (09:35:32 AM) tibbs: I think I get the zend thing now; php-api is for script compatibility; php-zend-api is for compiled extension capability. ? (09:35:45 AM) abadger1999: Does php define a "php api version" that isn't really used, or is it something that we've made up? (09:35:45 AM) RemiFedora: i've asked for php-zend-api, because it's match the sanity check done by php when loading module. (09:35:53 AM) spot: abadger1999: yes. (09:36:03 AM) spot: abadger1999: look at the bugzilla link remi posted, it explains it somewhat (09:36:07 AM) abadger1999: k (09:36:44 AM) spot: scop: lets go over the AI status (09:37:16 AM) scop: I believe provides/obsoletes and debuginfo are writeup stuff (09:37:32 AM) spot: yeah, i think so (09:37:47 AM) abadger1999: agreed (09:37:53 AM) spot: whereas, icon handling and RPMGroups were vetoed? (09:37:53 AM) scop: iconcache still not very clear yet -> followup? (09:38:15 AM) tibbs: rpmgroups wasn't exactly vetoed. (09:38:55 AM) tibbs: We were just asking for the ability to go ahead and get RPM changed to allow it to be optional without changing any guidelines which require it. (09:39:11 AM) spot: tibbs: ah, ok. i'll talk to paul and see if he's still willing to do it (09:39:43 AM) tibbs: At this point, though, everyone wants to see how the infrastructure develops before actually removing it from the guidelines. (09:39:56 AM) ***spot nods (09:40:02 AM) spot: rpm is only a bit in flux atm. :) (09:40:10 AM) scop: I think making Group optional would cause some compatibility issues (09:40:23 AM) scop: certainly at least on the specfile level (09:40:42 AM) tibbs: Nobody could point to anything specific, but you don't know until you actually try it. (09:40:49 AM) spot: scop: ehh, i'm not sure it would, the only issues i know of would be tools that depend on that field being populated (09:41:03 AM) spot: undefined Group is the same as undefined Vendor/Packager (09:41:22 AM) spot: (if it is flagged as optional) (09:41:43 AM) ***spot did a fair amount of testing with it the first time around (09:41:45 AM) Rathann|work: what's the motivation behind removing Group: ? (09:41:55 AM) scop: well, I'm sure it would cause those specfile level incompats (09:41:56 AM) spot: Rathann|work: the field is populated with garbage values (09:42:04 AM) scop: $ rpmbuild -bb foo.spec (09:42:10 AM) scop: error: Group field must be present in package: (main package) (09:42:27 AM) spot: scop: if rpm is patched to flag it as optional, it doesn't throw that error (09:42:35 AM) scop: yes, but older versions do (09:42:37 AM) spot: it would be an FC7+ only change (09:42:39 AM) Rathann|work: spot: we mandated buildroot and version and release, why can't we mandate group? (09:42:57 AM) f13: Rathann|work: because Group is unnecessary duplication and often times wrong data. (09:42:57 AM) tibbs: Because we have comps, which is more expressive. (09:42:58 AM) spot: Rathann|work: well, we could, but nothing is using the Group data (09:42:59 AM) scop: which means packagers who want to get rid of it must pay the price of maintaining different specfiles (09:43:12 AM) tibbs: Not that we haven't discussed all of this before. (09:43:13 AM) f13: Rathann|work: the 'Group' field isn't used by any of the tools that represent packages by groups. (09:43:28 AM) tibbs: There were proposals to encode the comps information into Groups. (09:43:32 AM) scop: f13, I believe Synaptic does use it (09:43:35 AM) scop: (FWIW) (09:44:14 AM) f13: scop: yes, but thats not really the "tool of choice" of Fedora. (09:44:17 AM) spot: scop: since it would be optional, packagers can weigh the tradeoffs (09:44:28 AM) f13: scop: Fedora's tools of choice being anaconda, yum, pirut, pup, all make use of comps through yum. (09:44:31 AM) abadger1999: scop: Or %if %{fedora}0 it. But they could hold off on making changes until FC8+ if they want everything to stay nice and neat. (09:44:34 AM) f13: same with the composition tool. (09:45:02 AM) abadger1999: scop: I agree with the synaptic/smart argument... until there's an alternative. (09:45:13 AM) scop: shrug, just pointing out that "nothing is using the Group data" is not true (09:45:38 AM) spot: i think that the idea is that storing package grouping metadata as hardcoded entries in the spec is a bad way to do package grouping (09:45:41 AM) abadger1999: (alternative to the Group tag, rather than alternative to synaptic/smart :-) (09:45:44 AM) f13: scop: ok, any of the tools we care about. (09:45:58 AM) f13: I'm with spot on this one (09:46:05 AM) spot: especially if someone wants to make Fedora Game Machine with their own custom groupings (09:46:05 AM) scop: f13, that's subjective (no, I don't personally care about synaptic) (09:46:08 AM) f13: package grouping is really up to the person creating the repo, not building the package. (09:46:14 AM) f13: as such, the group data needs to be outside the package. (09:46:29 AM) abadger1999: f13: -1 to not caring about smart/synaptic (09:46:33 AM) tibbs: That's an excellent argument. (09:46:44 AM) scop: I suppose rpmbuild would have to fill *some* Group info anyway (09:46:49 AM) abadger1999: +1 to the rest of your argument (09:46:57 AM) f13: scop: at some point, the Fedora board or whatever needs to draw a line regarding what package tools they care about. We can't hold things up because joe's package tool doesn't yet support it. (09:47:01 AM) tibbs: It would use (none) as with other optional fields. (09:47:10 AM) f13: and honestly, at this point, we care about yum and yum based tools. (09:47:59 AM) ***spot thinks that the reason we do changes over time, in phases, is to let Fedora contributors/packagers keep their preferred tools running (09:48:22 AM) abadger1999: f13: The line that I'm seeing we're crossing is that we don't have a place to store full group information for every package yet. (09:48:24 AM) spot: libs change, APIs change, for better and worse (09:48:39 AM) abadger1999: f13: So package managers that use Group tag information have nothing to port to. (09:48:44 AM) abadger1999: (yet) (09:48:56 AM) scop: I can't agree with shrugging off everything that is not yum based when discussing changes in rpm (09:48:57 AM) tibbs: Could we resolve the PHP issue before we close? (09:49:00 AM) f13: which isn't so bad when the data is oft times wrong. (09:49:14 AM) ***Rathann|work agrees with scop (09:49:35 AM) spot: scop: i agree with you as well (09:49:38 AM) spot: ok. PHP (09:49:47 AM) f13: scop: sure, but the only reason that synaptic/apt doesn't use comps is they chose not to. Not because they couldn't, they just chose not to. Too bad for them. (09:50:02 AM) tibbs: There were three changes proposed for the PHP guidelines: (09:50:04 AM) f13: their tool doesn't represent the same data as the installer, which it really should. (09:50:20 AM) tibbs: The first two are just hints for packagers: (09:50:36 AM) abadger1999: f13: No. comps is not inclusive. (09:50:41 AM) tibbs: note the %setup -q -c must be used because PHP package tarballs will always have a file that's not in any directory. (09:51:10 AM) tibbs: note that rpmdevtools provides a template, and that pear make-rpm-spec will generate a specfile for you. (09:51:29 AM) spot: The first two items seem like common sense to me. +1 to both (09:51:31 AM) tibbs: These are just hints to packagers and don't really change any guidelines. (09:51:35 AM) tibbs: +1 to them. (09:51:47 AM) lutter: +1 for adding them (09:51:53 AM) abadger1999: +1 (09:51:54 AM) f13: abadger1999: and Group is invalid and not inclusive either. (09:52:30 AM) f13: abadger1999: so really, they're trading a non-inclusive for incorrect. (09:52:33 AM) spot: f13? scop? (09:52:54 AM) f13: spot: I don't know enough about php to really offer a valid vote. (09:53:16 AM) spot: f13: you really don't need to know anything about php here (09:53:16 AM) f13: +0 I guess. (09:53:26 AM) spot: packages shouldn't dump crap in BUILD/ (09:53:35 AM) f13: right, +1 (09:53:41 AM) scop: sorry, was distracted (09:53:44 AM) spot: there are templates available for spec files, or you can have one automade. (09:54:29 AM) spot: ok, thats +5 (09:54:33 AM) scop: +1 to 1) obviously, both PHP specific and generic mention somewhere (09:54:43 AM) Rathann|work: php(api) and php-zend(abi) are cosmetic really, although it'd be great if they could be made consistent with python/perl/ruby (09:54:48 AM) spot: on item number 3, the API version check (09:54:59 AM) spot: i really want them to be consistent with the normal api standards (09:55:07 AM) scop: about 2), does "pear make-rpm-spec Sources.tgz" generate acceptable results? (09:55:29 AM) Rathann|work: scop: if it doesn't, it can probably be made to do so (09:55:32 AM) f13: well, python and perl are autogenerated by rpm aren't they? (09:55:36 AM) spot: when that change is made php(abi)/php-zend(api), i'd vote for it, but as is, -1 (09:55:39 AM) f13: should we wait until php is too? (09:55:47 AM) RemiFedora: i think so, only the %file must be updated (09:55:47 AM) tibbs: scop: according to discussion here, it generates something almost identical to the rpmdevtools template but filled in. (09:56:19 AM) tibbs: Unfortunately we have something of a broken situation unless PECL modules depend on the proper symbol. (09:56:38 AM) scop: tibbs, Rathann|work, ok, if it does create good stuff, +1 - but it needs to be verified before it goes to guidelines (09:56:42 AM) tibbs: PECL modules are the compiled extentions.l (09:57:11 AM) tibbs: As only F7 provides the symbol, we can still get it changed. (09:57:12 AM) ***Rathann|work should check if the php stuff he packaged once is already in extras... (09:57:21 AM) abadger1999: scop: That sounds reasonable. (09:57:29 AM) tibbs: If any of the Red Hat folks can talk to Joe Orton about it, it would be great. (09:57:46 AM) spot: there is an open bugzilla ticket where jorton seems to be responsive (09:58:02 AM) spot: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212804 (09:58:13 AM) abadger1999: RemiFedora, XulChris: How much might pear make-rpm-spec Foo.tgx change its output over time? (09:59:18 AM) RemiFedora: i think "pear make-rpm-spec" provides a fedora specific specfile, XulChris ? (09:59:30 AM) XulChris: RemiFedora: i havnt tried it (09:59:38 AM) abadger1999: RemiFedora: If so, that would eliminate my worry. (10:00:32 AM) scop: PEAR-Command-Packaging might however have some issues with that continuing to be the case in the future (10:01:18 AM) tibbs: The template is supplied by the Fedora packager, I think. (10:01:18 AM) scop: eg. if it creates php(abi) and friends, that might not work outside of Fedora and upstream could be interested in leaning towards compatibility... (10:01:46 AM) scop: ah, that sounds good (10:01:49 AM) tibbs: Yes, that template will only change if the Fedora packager changes it. (10:03:28 AM) tibbs: So are we resolved to try to get the symbol changed to php-zend(api)? (10:03:45 AM) spot: tibbs: +1 from me (10:03:47 AM) abadger1999: tibbs: +1 (10:03:56 AM) Rathann|work: consistency is good (10:03:57 AM) tibbs: Or was it php(zend-api) ? (10:04:15 AM) tibbs: Which is more consistent? It's a symbol provided by the PHP package. (10:04:22 AM) spot: php(api) and php-zend(api) (10:04:32 AM) tibbs: I'm not exactly sure what we're trying to be consistent with. (10:05:14 AM) spot: honestly, i don't care which one (10:05:38 AM) Rathann|work: tibbs: um, perl and python (10:05:57 AM) scop: perl is "different" (10:06:03 AM) scop: python and ruby (10:06:12 AM) Rathann|work: right (10:06:26 AM) tibbs: Right, but what is the set of parenthesized symbols they provide? (10:06:33 AM) tibbs: I guess I can do rpm --provides myself... (10:06:41 AM) scop: (abi) (10:06:53 AM) RemiFedora: python have python(abi) and python-abi (10:07:01 AM) Rathann|work: right (10:07:17 AM) tibbs: ruby has no parentiesized provides. (10:07:29 AM) scop: python(abi) is automatic, python-abi is there only for historical reasons for distros that didn't autogenerate python deps (10:07:29 AM) tibbs: Ah, but ruby-libs does have ruby(abi). (10:07:35 AM) spot: ruby(abi) = 1.8 (10:07:55 AM) tibbs: So there's no precedent for php-zend(abi) versis php(zend-abi) (10:07:57 AM) spot: php-zend(abi) says "the abi of php-zend" (10:08:06 AM) spot: which is different from the abi of php (10:08:22 AM) tibbs: But there's no php-zend package. (10:08:36 AM) spot: tibbs: does that matteR? (10:08:46 AM) tibbs: That's what I'm asking. (10:08:48 AM) spot: ruby(abi) is in ruby-libs (10:09:17 AM) tibbs: In any case, none of this matters significantly. (10:09:31 AM) tibbs: So who will tack this request onto that bug report? (10:09:38 AM) spot: i dont think it matters that there is no php-zend package as long as something provides php-zend(abi) (10:10:24 AM) ***spot looks at Remi (10:10:28 AM) scop: if it means "the zend abi of php", ie. a property of php, then php(zend-abi) would sound better to me (10:10:49 AM) ***spot really doesn't care. (10:11:00 AM) spot: since this is new ground, break it one way or the other. :) (10:11:03 AM) RemiFedora: i can add a comment on the bug the provide php(zend-abi) ... (10:11:07 AM) ***scop really needs to go now (10:11:20 AM) spot: RemiFedora: please do (10:12:09 AM) spot: ok, i'm going to go get lunch (10:12:19 AM) spot: thanks for the time all, and happy new year (10:12:20 AM) RemiFedora: does i ask J.Orton to also provide the macros.php on FC6 ? (10:12:38 AM) spot: RemiFedora: if you want to use it in FC6. :) (10:12:58 AM) abadger1999: So long scop, spot (10:13:06 AM) tibbs: I will write up the other two items into the guidelines and present a draft to the list. (10:13:45 AM) abadger1999: RemiFedora: Could you explain what a "channel" is? (re your second email) (10:14:04 AM) RemiFedora: php.net is the main channel for extensions.. (10:14:10 AM) XulChris: abadger1999: its like a repo (10:14:57 AM) tibbs: Like every other language these days, PHP has its own packaging system. (10:15:08 AM) f13: gah (10:15:22 AM) tibbs: It's not nearly as intrusive as eggs or gems, though. (10:16:23 AM) abadger1999: k (10:16:51 AM) tibbs: XulChris: what does the channel get used for in the RPM world, though? (10:16:57 AM) tibbs: Just version checks and signatures? (10:17:13 AM) XulChris: tibbs: i use it to check for updates (10:17:32 AM) tibbs: I guess the question is, what breaks if it isn't there? (10:17:46 AM) XulChris: the install (10:18:21 AM) RemiFedora: and the build.. (in mock) (10:19:07 AM) tibbs: I guess you can't register the module if the channel isn't already set up. (10:19:19 AM) XulChris: that too (10:19:41 AM) abadger1999: f13: Group tag is a poor technology. But jeremy is against using comps to replace it. (10:19:45 AM) tibbs: But it doesn't actually contact the channel server for anything; it's just a formalism. (10:20:08 AM) tibbs: abadger1999: Just change your packages to say Group: none. (10:20:22 AM) abadger1999: f13: I liked Nicholas Mailhot's suggestion after he explained it. (10:20:35 AM) XulChris: tibbs: not sure what your asking, we need the channels as pear users expect them to be there (10:21:11 AM) tibbs: Someone asked what the channel is used for. (10:21:18 AM) tibbs: I'm trying to determine that. (10:21:48 AM) XulChris: tibbs: basically all pear commands are tied into channels (10:21:56 AM) XulChris: its pretty much ingrained into pear (10:22:10 AM) tibbs: I know, but you shouldn't be running pear in an RPM world; you can screw your system. (10:22:40 AM) XulChris: not sure i agree with that statement entirely (10:22:43 AM) RemiFedora: we must run pear in rpm scriplet... (10:22:45 AM) tibbs: Maybe not you, but Joe Random User certainly. (10:22:54 AM) f13: abadger1999: I don't recall what his suggestion was. (10:23:03 AM) f13: abadger1999: jeremy was against using comps to list every package in existance. (10:23:20 AM) XulChris: you shouldnt be using pear to install/uninstall packages that already have rpms, but pear does more than this, just type pear --help (10:23:23 AM) f13: abadger1999: however what could be accomplished by Other Tools is list the packages grouped by a comps file, then everything else in 'ungrouped' (10:23:29 AM) tibbs: XulChris: Yes, I know. (10:23:35 AM) tibbs: But it's still dangerous. (10:23:40 AM) abadger1999: f13: Exactly. And synaptic/smart/repoview would benefit greatly from listing every package in existence. (10:24:22 AM) abadger1999: Just look at the mess that is http://fedoraproject.org/extras/6/i386/repodata/repoview/__nogroup__.group.html (10:24:23 AM) RemiFedora: "Joe Random User" need pear until all PHP extensions available in RPM repo. (10:24:37 AM) tibbs: RemiFedora: Yes, I know that too. (10:24:38 AM) abadger1999: If I actually want to find something in there, it's a nightmare. (10:25:08 AM) f13: abadger1999: it'll be a nightmare in whatever group gets the bulk of the "unintersting" packages too. The -devel packages, the libs that are just there for other top level packages, etc... (10:25:15 AM) XulChris: tibbs: also we are talking about joe average developer, not joe average user since pear is a developers tool (10:25:47 AM) tibbs: "pear upgrade-all" is not intended to be a developers tool as I understand things. (10:26:18 AM) abadger1999: f13: That's what makes Nicolas's proposal nice. (10:26:40 AM) XulChris: tibbs: it is, joe average user relies on joe average administrator to keep pear packages up to date (10:26:41 AM) abadger1999: He has separate ideas for categories and groups. (10:27:16 AM) tibbs: XulChris: First, that's obviously untrue. And second, administrator does not equal developer. (10:27:18 AM) abadger1999: So a package is marked as belonging to seven different categories. (10:27:27 AM) XulChris: tibbs: well you need root to run that command properly (10:27:45 AM) abadger1999: And the user is better able to tell what package they want. (10:28:14 AM) abadger1999: Meanwhile, generating a comps type file happens through the Group mechanism. (10:28:16 AM) tibbs: XulChris: Yes, and? (10:28:43 AM) tibbs: You seem to be forgetting that a large portion of desktop users have root, are not developers and are not qualified to be administrators. (10:28:57 AM) XulChris: tibbs: and there are many ways to screw your system as root, so we shouldnt bother trying to protect users (10:29:00 AM) tibbs: They should stay away from pear at all costs. (10:29:26 AM) tibbs: So if they don't need to run pear, then it's back to the original question: what is the channel for? (10:29:30 AM) RemiFedora: a large number of pear extensions are now available in Extras, we probably could patch pear to display a warning (you should try yum first) (10:29:49 AM) tibbs: You said it's because pear users expect to be there, but we've established that there should be few actual pear users. (10:29:54 AM) XulChris: tibbs: they _do_ use pear, just not for installing and uninstall pear packages that arent already rpms (10:30:17 AM) XulChris: er that *are* already rpms (10:30:19 AM) tibbs: Now you're going circular. (10:31:05 AM) abadger1999: Add a category of packages to a Group. Then the installer can see it's one package one group selection. (10:31:49 AM) abadger1999: A third party spin that concentrates on scientific applications can have a different category => Group mapping. (10:32:46 AM) XulChris: tibbs: do you modify Fedora's perl so that you cannot use its built in cpan updater? (10:33:33 AM) tibbs: Well, cpan is an add-on, not built-in, and you can package up any Perl module without registering any channels with it. (10:33:48 AM) XulChris: tibbs: thats becasue perl only has 1 channel, cpan (10:34:12 AM) tibbs: Cpan is not involved in any way whatsoever with installing Perl modules. (10:34:30 AM) XulChris: php has 2 channels, one for pear modules and one for pecl modules, with the possibility to have more channels for other repos like phpunit has now (10:34:45 AM) XulChris: tibbs: its a repository (10:34:49 AM) tibbs: You're just not getting it. (10:34:52 AM) XulChris: thats all a channel is, a repository (10:35:28 AM) tibbs: I'm asking, in the context of a world in which RPM is used for installations, what use the channels are. (10:35:49 AM) XulChris: tibbs: what use is a yum.repo.d/ file? (10:36:04 AM) tibbs: Sorry, now you're really off in left field. (10:36:14 AM) XulChris: its just a way to specify a repository (10:36:19 AM) XulChris: thats all a channel is (10:37:01 AM) RemiFedora: a channel create a "namespace" in the local pear registry, which is mandatory to build and install extensions (10:37:08 AM) tibbs: RemiFedora: Thank you. (10:37:09 AM) XulChris: if every single pear pecl and whatever file is packaged as an RPM you could agrue we do not need pear channels (10:37:32 AM) tibbs: But they still would fail to install because of lack of the appropriate namespace being set up? (10:37:45 AM) XulChris: if there was any overlap (10:37:53 AM) XulChris: like phpunit has overlap (10:38:06 AM) XulChris: but phpunit is the only case i know of that has the same name (10:48:52 AM) abadger1999: f13: Here's Nicolas's initial post: https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00700.html (10:49:05 AM) f13: abadger1999: I really don't have the bandwidth to discuss this right now :/ (10:49:13 AM) abadger1999: The idea was clarified throughout the thread, including into the next month. (10:49:19 AM) abadger1999: f13: k. (10:49:21 AM) scop: tibbs, CPAN.pm is very much in the business of installing Perl modules, and it's included/built in in core Perl since $forever (10:49:46 AM) abadger1999: Doesn't matter ATM. (10:49:56 AM) RemiFedora: about PHP Packaging, can we remove "Requires php" which doesn't conform to the general Guidelines (php already required by php-pear) (10:50:09 AM) tibbs: scop: you missed the point, but whatever. (10:50:28 AM) tibbs: I was indeed incorrect in thinking that it was an addon. (10:51:09 AM) RemiFedora: and use php-common when we need a "versioned" requires (10:52:00 AM) scop left the room ("Leaving"). (10:52:19 AM) f13: is there a handy shortcut for packaging man files? Just %{_mandir}/*/* ? (10:52:22 AM) XulChris: RemiFedora: i think we already discussed that a long time ago, and we decided php was only required if it was like a new version that is not available in an existing supported distro (10:52:52 AM) XulChris: so like if fc8 has a package that requires php 6, then that needs to be added, otherwise you can leave it out (10:53:15 AM) f13: isn't that what the php(abi) stuff would sort out? (10:53:19 AM) f13: should it be done automagically (10:53:22 AM) f13: like python (10:53:28 AM) XulChris: ya (10:53:34 AM) XulChris: good point (10:53:41 AM) XulChris: was that approved? i was busy earlier :) (10:53:43 AM) RemiFedora: yes, i agree, but "requires php" still a must according the PHP guidelines.. (10:55:17 AM) RemiFedora: so my comment is to remove it from the Guidelines (10:55:37 AM) tibbs: I would tend to agree. (10:56:41 AM) tibbs: For some reason I thought we intended to remove that when we added the php-abi stuff. (10:57:08 AM) RemiFedora: php(zend-api) is only for pecl extension. (10:57:21 AM) tibbs: Yes, I know that. (10:57:50 AM) tibbs: Crap, is it "api" or "abi"? I keep getting confused. (10:58:31 AM) RemiFedora: oups, i've post php(api) and php(zend-abi) ... (10:59:10 AM) RemiFedora: should i change to  php(abi) and php(zend-abi) ? (10:59:38 AM) tibbs: php-api is what's provided by the current php package. (11:00:04 AM) RemiFedora: yes, and this must be keep (present for a very long time) (11:01:16 AM) tibbs: Hmm, on fc6, the php-common package provides php-api. Interesting. (11:01:48 AM) tibbs: I guess it got split, and php-common doesn't require php, either. (11:02:02 AM) RemiFedora: yes, php is the apache module, php-cli is the CLI, both requiring php-common (11:02:12 AM) tibbs: Does that influence whether we can remove Requries: php from the guidelines? (11:03:16 AM) RemiFedora: no, i don't think (11:03:18 AM) tibbs: It probably means that we need to remove it, because otherwise installing a php-module pulls in apache when perhaps you didn't want that. (11:03:59 AM) RemiFedora: a most pear/pecl extension works with php-cli (no need for a web server) (11:04:13 AM) RemiFedora: s/a/and/ (11:04:40 AM) tibbs: So, yes, it looks like we really do need to remove that bit. (11:05:30 AM) RemiFedora: and if we need a versioned requires, we should use Requires: php-common >= x.x (11:07:03 AM) RemiFedora: Ok for (provides by php-common) : php-api = %{apiver}, php(abi) = %{apiver}, php(zend-abi) = %{zendver} ?? (11:07:28 AM) tibbs: Well, let's think about it. (11:07:38 AM) tibbs: php-api is about source-level compatibility, correct? (11:08:34 AM) tibbs: As in, when they revise the interpreter so that old code no longer runs, that value will increase. (11:08:48 AM) RemiFedora: i don't really know, as it doesn't change... since 2004 (11:09:01 AM) tibbs: Wasn't the last time they broke source-level compatibility, though? (11:11:00 AM) RemiFedora: a lot of source-level compatibility (C or PHP) has been broken since 2004... (11:11:27 AM) tibbs: Crap, then that symbol is essentially useless. (11:11:46 AM) tibbs: The way Perl handles this is so much cleaner. (11:12:49 AM) tibbs: So PEAR modules should have a versioned requires on php (or php-common) (11:13:09 AM) tibbs: and PECL modules should require a specific version of php(zend-abi)? (11:13:51 AM) tibbs: The thing is, you don't want to have to rebuild every PEAR module for every minor php update. (11:15:07 AM) RemiFedora: PEAR have a requires on php-pear, no need for requires php, only if php-common >= x.x (11:15:28 AM) tibbs: FC5 has no php-common, though. (11:16:02 AM) RemiFedora: yes. And this will not cause rebuild. (11:16:50 AM) tibbs: Now I don't understand. What do you require on FC5, then? (11:16:52 AM) RemiFedora: rebuild are only requires for pecl when zend-api change (5.1 -> 5.2 p.e.) (11:17:18 AM) RemiFedora: only php-pear (11:17:45 AM) tibbs: And what happens to PEAR modules if PHP6 comes out and breaks compatibility? Modules are just silently broken? (11:17:47 AM) RemiFedora: and php > x.x is special version is needed. (11:19:10 AM) RemiFedora: difficult to know. requirement are provided by package.xml, but only for minimal version... (11:20:23 AM) tibbs: I guess in the absense of php(:MODULE_COMPAT_version) we'll just have to use php-common >= whatever and deal with problems when they happen. (11:20:34 AM) RemiFedora: yes (11:21:11 AM) tibbs: OK, so we have four possibilities: (11:21:43 AM) tibbs: FC5 PEAR modules need to require php-pear and php >= version if they require a particular version. (11:22:04 AM) tibbs: FC6+ PEAR modules need to require php-pear and php-common >= version if needed. (11:22:47 AM) tibbs: FC7+ PECL modules need to require php(zend-abi) (or is it zend-api?) = version. (11:22:57 AM) tibbs: FC5,6 PECL modules need what? (11:23:44 AM) RemiFedora: FC5 only php-api, but will not detect compatibility (11:24:04 AM) RemiFedora: FC6+ php(zend-abi) = version (11:24:25 AM) tibbs: But we may not be able to get FC6 PHP fixed to probide php(zend-abi). (11:24:57 AM) tibbs: I does currently provide php-zend-abi, though. (11:25:05 AM) RemiFedora: FC6 and FC7 already provide php-zend-api :) (11:25:15 AM) tibbs: I'd hate to need separate things for FC5, FC6 and FC7, though. (11:25:46 AM) RemiFedora: i agree, so i will also ask J.Orton for FC5 (11:25:54 AM) tibbs: And it's definitely "php-zend-abi"; nothing currently provides php-zend-api. (11:26:22 AM) tibbs: Which makes sense; this is about dlopening existing binaries, hence ABI. (11:26:47 AM) RemiFedora: yes, abi, your right (11:27:20 AM) tibbs: So it's php(api) and php(zend-abi). API for the first and ABI for the second. (11:28:14 AM) RemiFedora: Like this ;) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212804#c6 (11:30:06 AM) tibbs: Yes, looks like you got it right there. (11:30:28 AM) tibbs: So we'll see what he says and go from there. (11:35:26 AM) RemiFedora: i'm the reporter for this RFE, so i could post on the packaging ML when it goes on..