[Pkg-mediawiki-devel] packaging of MW extensions

[Romain Beauxis]

Le mardi 22 juin 2010 11:48:10, Thorsten Glaser a écrit :
> Dixi quod…

	Hi !

> > On Mon, 21 Jun 2010, Romain Beauxis wrote:
> > > The current extensions package should be easy to extend. Basically, you
> > > can  give the svn url of one file of the extension, pull all the rest
> > > and synchronise later.
> >
> > 
> >
> > Ah, interesting. Do you put all extensions into one (source)
> > package, or do you split them?
> 
> For split packages, I attached an actually working package
> of how I would do them, as a base of discussion. I’d only
> keep the debian/ part in svn.


Hmmm...

I am not convinced by the idea of splitting the source package. However, 
if you have strong arguments, I am open to the idea. 

Let me try to take some time to explain how I maintain the current package.

The current package contains a file named svn-revisions. Each line in this file 
corresponds to the uri of a svn file that needs to be checked-out. For instance:

http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_15_3/extensions/Cite/Cite.i18n.php - Cite - base - usr/share - no - 48711

This tells that the file Cite.i18n.php belongs to the Cite extension, is shipped 
in the mediawiki-extensions-base package, should be placed in /usr/share/mediawiki-extensions/base/Cite,
should not be linked in /etc/mediawiki-extensions/extensions-available and the latest revision 
checked was 48711.

You update the extensions by using the check_revisions.pl script. The options 
for this script are:
Use: check_version.pl -v -u -s /path/to/svn-urls
  Option -u forces update of each file
  Option -v turns verbose mode on
  Option -s skips svn revision check and other files check

This script generates the whole packaging structure, located in dist/, as well
as the dh_link files in debian/.

-s puts the latest svn revision checked to 0, which may force the update of the files.

-u is actually not well documented. It is used in conjonction with -s to not update
the files but only generate the files in debian/

-v gives more informations about what is going on.

When checking a file, the script also checks for the other files in the same directory. If 
it finds a file that is not listed in the urls, it asks you if you want to add it. This 
is useful to  make sure you did not miss some files.

When you want to add a new extension, you simply have to add one of the files
in the lists of urls with revision 0. When running the script, it will then ask you about
the other files in the same directory.

What you can do, if you want to try, is to checkout the latest trunk:
  svn checkout svn://svn.debian.org/svn/pkg-mediawiki/mediawiki-extensions/trunk

Then run the update script in verbose mode:
  cd trunk
  ./check_versions.pl -v ./svn-revisions

And see what is going on.

what I meant by splitting is splitting the url file. The current file contains
all the svn url so the update script takes a while to run. It would be better to be 
able to run it for a specific extension only..

This does not need a lot of time, I may do it soon.

Also, the checkout script may have bugs but it seemed to be working fine so far..

So, in your case, you should add for instance this line on top of the svn-revisions 
file:
  http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/News/News.php - News - base - usr/share - yes - 0

And run the update script again.

The policy for the package where to put the extensions so far is: 
 if the extension requires an additional dependency, put it in a seperate package, 
otherwise put it in base.

The location of the files should always be usr/share unless the files need a specific
location, like optionToTable.php  for openid which needs to be available in 
var/lib/mediawiki/maintenance.

The link should be yes for only one file per extension, which is the file that needs
to be included to enable the extension.

Some files from the extension should be excluded, for instance in the case of fckeditor,
we do not copy the fckeditor/ directory because we use the packaged version. The same
goes, as usual, for the COPYING/LICENSE/.. files which information is sumarized in debian/copyright

A limitation of the script is that it does not remember the file you refused. Hence,
you will have to refuse for instance fckeditor/ each time you run the script -- patch to fix
that welcome :)

Of course, you also need to update debian/copyright and possibly debian/control(.in) 
when adding a new extension.

Ok, I think that is enough for now. I let you play with it if you're interested. Don't hesitate
to ask for more informations..

Ah, also, I have no particular need for cdbs for debian/rules but I like to have smaller
debian/rules files... :-)

Romain