Spec URL: http://ianweller.fedorapeople.org/SRPMS/mediawiki116-ConfirmEdit/0-1.20110116svn80427/mediawiki116-ConfirmEdit.spec SRPM URL: http://ianweller.fedorapeople.org/SRPMS/mediawiki116-ConfirmEdit/0-1.20110116svn80427/mediawiki116-ConfirmEdit-0-1.20110116svn80427.fc14.src.rpm Description: The ConfirmEdit extension enables a simple text Captcha that will probably not allow most bots to edit your site.
Full list of extensions we currently use: SpecialInterwiki -- not installing since we don't use it Cite Click -- not installing, functionality built into MW 1.14 and later ParserFunctions Auth_FAS ConfirmEdit Lockdown There's some other extensions that have been requested and we can install, I need to go find them.
(Shit, I meant to make that comment to the tracking bug.)
* Sources match upstream * License OK and matches source files * %doc files do not affect runtime * License text not included with upstream or in %doc (OK, might want to ask upstream about this) * Package is code I think that the Python script should be moved into a separate subpackage so that the script can be dependency complete - no sense in having bits on the disk that are going to traceback the minute you try and use it. There's also no sense in having python-imaging pulled in by a MW extension that doesn't require the python piece in order to work. I think that the solution to this is to move the python script into a subpackage and have that subpackage require python-imaging. I'll reach out to some other folks to see what the "official" stance on this issue is.
There's some missing context here -- jds2001 and I were talking about this at the hotel at FUDCon. I feel pretty opposed to making a subpackage, and this reasoning is extremely subjective, so we basically need someone who can reference packaging guidelines and make a decision. :) I read through them and it wasn't really clear whether we should have a subpackage or not.
I think we need a bit more context. Does the disagreement boil down to dependency bloat for an optional feature? If so, the guidelines aren't going to tell you much about that. This seems to be a leaf package, so the only thing to really consider is how much dependency bloat we're talking about and whether those dependencies will cause problems (security exposure, etc.) in the situation where the package is to be used.
I think the problem is that Ian doesn't want to do a subpackage *or* require a dep on python-imaging. I'm thinking that one or the other has to be done. If you don't do either, there's a dependency problem in the package (the python script will give an ImportError when you try and run it).
OK, then what is the script used for? Checking the documentation, it looks like it's a setup script for one of the supported captcha types. But one of the other captcha types requires a full TeX installation and there's no discussion about adding dependencies on that. Honestly this is the kind of thing we'd handle with Suggests:. Since we don't have that, personally I'd leave it up to the maintainer to split the package or not. Note that for the end user the result is pretty much the same. No subpackage, and they have to install a python dep if they want to use that captcha type. With a subpackage, they have to install it if they want to use that captcha type. I don't see much difference, honestly, as long as the stuff that needs installing is documented well enough.