From Fedora Project Wiki
(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 dlopen()ing 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..