16:21:34 #startmeeting fpc 16:21:34 Meeting started Wed Mar 16 16:21:34 2011 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:21:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:22:21 #topic Minor PHP Guildelines Changes for doc files placemen, https://fedorahosted.org/fpc/ticket/69 16:22:44 there's some alias/shortcut I'm missing, but we can fake it 16:23:01 So, nothing says where doc files have to live, only that they be marked as %doc. 16:23:16 Really? … /usr/share/pear/doc … seems kinda horrible 16:23:37 No worse than /usr/share/man/man1/whatever. 16:23:42 I'm ok with it 16:24:01 geppetto: why horrible? 16:24:04 That's different … as that's where the man command looks 16:24:14 And /usr/share/pear/doc is where pear looks. 16:24:28 I could bikeshed that perhaps something under /usr/share/doc would be better, but meh. 16:24:47 tibbs|h: +1 16:24:53 Are there only five of us? 16:25:00 so far 16:25:19 what do other distros do in this case? 16:25:20 R, for example, has documentation as part of the module and that documentation is buried down under the module directory. 16:25:28 so, we'll have to be unanimous to approve anything 16:25:40 rdieter: yeh, that's what I was thinking 16:25:54 One thing to note is that nothing says that anything is wrong with putting the documentation where pear wants to find the documentation. 16:26:13 Which is why I think this is rational. 16:26:27 So, really, this guideline isn't a big dea. 16:26:40 tibbs|h: R itself seems to use: /usr/share/doc/R-2.12.2 16:26:57 Not really, no. 16:27:14 /usr/share/R/library/*/html/*, for example. 16:27:21 Ahh, a few of the modules use … /usr/share/R/library//html 16:27:56 RemiFedora: I don't understand why you need that guideline to be approved in order to fix the spec generator, though. 16:28:02 * geppetto sighs … I think we should at least require people to create aa symlink from /usr/share/doc to whatever other random place they are using 16:28:17 Even for manpages? 16:28:20 Just because, the move was a common pratice for a very long time 16:28:34 The symlink was mentioned, though. 16:28:44 In IRC discussion, though it's not in the ticket. 16:28:51 RemiFedora: Am I misremembering that? 16:28:53 And some of us (pear packages maintainer) think it should be "explicit" 16:29:34 Yes, (as you say) the symlink doesn't seems really usefull 16:30:05 I do think the argument would be stronger if there was a pear documentation browser of some sort. 16:30:20 R does what it does because it has documentation display methods built in. 16:30:44 Yes, if you could do: pear foo … to read the docs for foo, and that required it to be in /usr/share/pear … it still wouldn't be great, but I could understand it more 16:31:12 Currently the point is to keep from breaking the pear manifest, I think. 16:31:24 the "pear list-files foo" gives you a list of installed, which is actually broken (when doc are moved) 16:31:24 yeh, but I can't say I care about that 16:31:28 so... there is no pear foo to read the docs? 16:32:04 does "pear list-files foo" being broken have any non-cosmetic impact? 16:32:22 I don't think 16:32:41 ok, if it did, I was going to argue these should not be marked %doc then 16:33:03 hm apparently debian has /usr/share/doc/php-pear 16:33:03 right, otherwise a nodocs install would break things. 16:33:59 are we ready for a vote, or do folks have more questions or comments to make? 16:34:07 ready. 16:34:21 could php-pear be patched to look in /usr/share/doc/php-pear instead? 16:34:27 I'm guessing yes 16:34:28 yes 16:34:31 Can they just do a reverse symlink … so /usr/share/pear/doc/blah => /usr/share/doc/blah 16:34:40 I think you'd have to patch each package manifest. 16:34:48 ah 16:35:00 that's a bit too much work to put on maintainers 16:35:21 adding a single symlink at %install time? 16:35:34 probably we should write %[pear_docdir} (instead of /usr/share/pear/doc) in the guidelines, then, if we want to change this, we patch php-pear, and then all packahe will be redirected to the new path 16:35:42 I thought we did. 16:35:56 (the %{pear_docdir} macros already provided by php-pear) 16:36:04 And already mentioned in the guidelines. 16:36:26 RemiFedora: +1 (in this proposal, yes) 16:36:28 I see no instance of /usr/share/pear/doc in the guidelines. 16:36:45 in the ticket 69 it mentions /usr/share/pear/doc 16:36:58 Ah, yes, the proposal. 16:37:17 debian packaging doesn't do any patching of the manifest and still puts docs in /usr/share/doc AFAICT 16:37:45 If it's a simple patch to pear, that would I think be preferable. 16:38:11 Rathann: What is /usr/ahre/doc/php-pear then? 16:38:22 Oh, nevermind … I didn't read that right 16:38:49 * Rathann is just looking at a couple of random php pear packages in debian 16:39:05 I'll update it with that substitution. 16:39:10 Yeh, so -1 on 69 as it is … +1 is it's changed to /usr/share/doc/php-pear/blah 16:39:17 geppetto: for example http://packages.debian.org/sid/all/php-mail/filelist 16:39:28 I'd go for putting the files where pear wants but including a symlink in /usr/share/doc, or patching pear to just look where we put the files. 16:39:39 now the draft mentions only %{pear_docdir} , so we can consider what it's value is separately 16:39:43 Rathann: *nods* 16:39:45 But I don't know how reasonable the latter is; RemiFedora would have to tell us. 16:39:47 tibbs|h: I kind of dislike putting symlinks in packages 16:40:04 Rathann: +1, that's asking for trouble sometimes 16:40:08 Uh, do you also dislike putting files or directories in them? 16:40:40 the risk is accidentally packaging stuff from those symlinks instead of the real location 16:40:45 rdieter: You mean like when you replace a directory with a symlink? ;) 16:40:55 limburgher: that's one of the dangers 16:41:07 i am against of /usr/share/doc/pear, because we use /usr/share/doc for "per-package" docs. 16:41:30 OK, I've ammended the draft to not mention path, can we vote on it now? 16:41:39 Rathann, php-pear-Mail doesnt install docfile (from its manifest) 16:41:47 * Rathann is of the opinion that if there's no special pear command for viewing docs then their docs should go into %{_docdir} as with all regular packages 16:41:51 racor: /usr/ahre/doc/HTML? 16:41:54 that said, /usr/share/pear/doc or similar would be OK with me. 16:41:58 Well, spelled right. 16:42:01 tibb|h: Bug 16:42:01 RemiFedora: can you give me an example of a package which does? 16:42:50 php-pear-Date php-pear-DB 16:42:54 This one appears to have html http://packages.debian.org/sid/all/php/php-geshi/filelist 16:43:02 racor: Care to quote any guideline or standard that mentions that? It would be useful to know. 16:43:28 tibbs|h: No standard, just convention ever since rpm is around. 16:43:42 OK, so no. 16:44:16 tibbs|h: Yes, it's not against the law, nevertheless /usr/share/HTML is stupid 16:44:16 geppetto: but no html under /usr/share/php, only under /usr/share/doc 16:44:45 Rathann: yes, that's what I meant 16:45:03 ok, let's go ahead and vote, and continue discussion if this does not pass as-is: "PEAR documentation provided by upstream are installed in %{pear_docdir}, should stay there, and must be marked as %doc" 16:45:11 +1 16:45:15 -1 16:45:23 racor: well, since we think it's stupid and some people don't, let's pass a guideline that says all docs must be under /usr/share/doc unless necessary for program operation (but then they shouldn't be mared as %doc) 16:45:33 geppetto: care to mention why? 16:46:00 I guess if nothing actually cares where these files go, they should go where users will look for them. 16:46:17 +1 16:46:18 Rathann: What Rathann said, basically … I don't think the benifit of making pear list-files happy outweighs people "knowing" docs are in /usr/share/docs 16:46:37 rdieter: ^ 16:46:38 to be clear, the draft now does not mention a specific location, only %{pear_docdir} 16:46:53 unless you're arguing that %{pear_docdir} macro should not be used? 16:47:16 Well if pear_docdir was changed to be under /usr/share/doc … then I'd be fine 16:47:19 my vote was for ticket #69 which explicitly mentions /usr/share/pear/doc 16:47:48 sigh, ok, I was hoping to consider these issues separately, but I seem to be in the minority 16:47:59 I don't think explicitly listing the directory will fly in any case. 16:48:10 Since everything else about pear file locations is macro-ized. 16:48:45 It would really be helpful to know if pear can simply be fixed to cope with the current arrangement. 16:48:51 racor: so, does the ammended wording change your vote? 16:50:30 tibbs|h: Maybe, can it check multiple locations? 16:50:51 I have no idea; I'm not the expert here. 16:51:01 -1 from me unless there are comments from users confused about the location of the docs 16:51:09 doc_dir is a pear configurable option 16:51:21 Rathann: Good point, are there BZs or anything on this? 16:51:23 but since Debian is putting the docs in /usr/share/doc then I think there aren't 16:52:00 rdieter: yes, it changes my vote, I am not willing to card-blanche changing this directory 16:52:04 being close to upstream is good, but pear upstream has their own packaging system and we have ours 16:52:22 Perl 16:53:08 Perl packaging is completely regular and rarely conflicts with our packaging. 16:53:09 limburgher: yes, I changed my vote, exactly because of experiences with perl 16:53:46 Oh, well, this is going nowhere fast. 16:53:48 ok, looks like we're at a stand-still then, those with objections, please mention your grievances in https://fedorahosted.org/fpc/ticket/69 for posterity 16:54:43 #info ticket #69 , php guidelines changes for doc files placement, nack'd 16:55:01 anything else we should look at? 16:55:08 But I'm dismayed if we now have one person who will always vote against a guideline with a macro-ized directory location. 16:56:00 Well … it depends on where the macro points 16:56:10 tibbs|h: Then lets specify this macro-ized directory. 16:56:28 We don't specify the majority of the ones we have now. 16:56:49 "The php-pear package in Fedora Core 5 and above (version 1:1.4.9-1.2) provides several useful macros:" 16:56:51 racor: correct, a mistake, which is close to having run down eg. perl 16:57:04 But if they point to the correct place already, it doesn't matter as much 16:57:06 And lists five of them, without mentioning their values at all. 16:57:19 * abadger1999 here now 16:57:30 * abadger1999 reads back 16:57:31 abadger1999: hi 16:58:43 argh, trac looses your text when you try to commit in conflict with someone else 16:59:00 imo, by rejecting the *current* value of %{php_docdir}, we pretty much invalidate the current php guidelines as well 16:59:17 this proposal was only an addition and clarification 16:59:33 rdieter: well, nobody noticed before, apparently 16:59:47 Not necessarily. 17:00:05 just sayin 17:00:41 racor: Can you elaborate a bit on why the macro(s) is/are a mistake and the resulting issues? 17:00:47 or, I can collate folks responses and post into the ticket, if you give a one-line summary here. 17:01:17 *sigh* /me writes his text again 17:01:45 Copy it to the clipboard before you submit it. 17:03:46 someone should probably open a bug against php-pear to ask for "doc_dir" relocation ? 17:03:51 limburgher: Some people have repeatedly changed many of the perl macros during f15's development cycle. 17:04:48 Nothing would stop them from doing that anyway. 17:04:56 the result is inconsistency and caos when looking into the details of f15's perl packages. 17:05:24 And I don't think they changed the macros; they just changed internal Perl configuration values. 17:05:40 racor: Wouldn't a rebuild fix that, if the perl packages are consistently macroized? 17:05:52 ok, posted 17:05:53 an attempt to bring some order into the caos by a mass rebuilt causes further havoc due to rpm's dep checker changes. 17:06:03 If anything, I expect that any macros would be dynamically defined by calling perl or pear or whatever. 17:06:07 s/causes/caused/ 17:06:12 ah. 17:06:17 We certainly shouldn't be hardcoding their locations in the guidelines. 17:06:48 tibbs|h: yes, they changed perl, from which (all?) of these macros are derived from. 17:06:53 tibbs|h: agreed. 17:07:53 Rathann, FYI, we can change (easily) php-pear to put/look for doc in %{_docdir}/pear/foo but probably not in %{_docdir}/%{name}-%{version}-%{release} 17:08:28 RemiFedora: that'd be acceptable as well I guess 17:08:45 Rathann: racor already indicated that he'd reject that. 17:08:59 Personally I'd be for it. 17:09:09 me too 17:09:16 (for) 17:09:29 ditto, macros are good if used for good and not evil. 17:09:35 yes, I am opposed to this (c.f. rpm'd DEFAULTDOCDIR and the implicit %doc behavior) 17:09:46 racor: why? 17:10:13 He pretty much covered that already. 17:10:17 Rathann: To put it very simplistic: I can't find a package called HTML 17:10:56 Of course, nothing says that you have to. 17:11:11 But it seems there's an unwritten rule that we're supposed to abide by. 17:11:26 tibbs|h: except of 15 years of history 17:12:26 we're approaching an hour, abadger1999, did you catch up or have anything to add? 17:12:59 $ repoquery -qf /usr/share/doc/HTML 17:12:59 fedora-release-notes-0:13.2-2.fc13.noarch 17:12:59 kde-filesystem-0:4-35.fc13.noarch 17:13:20 racor: file bugs against those three 17:13:21 fwiw … I don't mind %{_docdir}/pear/foo 17:13:38 Three? 17:13:46 and all the others, too 17:13:46 +1 to guideline 17:13:57 abadger1999: Sorry, which one? 17:14:08 Unfortunately it's been revised a bit. 17:14:22 Really... I'm okay with any of the proposals. 17:15:08 Best: Use %{pear_docdir} and define it to %{_docdir}/pear/foo 17:15:11 gholms|work: looks like it's kde-{i18n,l10n}-$lang packages which keep docs there 17:16:32 So... we done? 17:16:45 I think so, I can't stay much longer 17:16:48 looks that way. 17:16:52 yep 17:16:53 thanks all. 17:16:58 #endmeeting