[Pkg-mediawiki-devel] packaging of MW extensions

[Thorsten Glaser]

I’m not replying in the order you wrote, just in case you wonder.


On Tue, 22 Jun 2010, Romain Beauxis wrote:

> Let me try to take some time to explain how I maintain the current package.
[…]

This sounds nice and easily extendible, but see my points below.

> 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.

php-openid? mediawiki-extensions depends on it…

I would not be against this thing (collect extensions that don’t
have additional dependencies in one package) if I didn’t think
the points I will be making below outweigh the benefits of it.

> The location
[…]

Sounds reasonable.


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

I’m mostly using *one* debian/rules sort-of-template file where
I just uncomment the calls the package needs, shared across most
of my packages. To each his own, I suppose. This one’s closest to
php-htmlpurifier (which isn’t, strictly spoken, mine even though
I re-created the packaging from scratch due to bugs in the previ-
ous).

Also, this is “easier” (less dependencies, especially less ver-
sioned dependencies) and works on etch (even sarge if compat were
set to 4; I only raised it to 5 due to lintian; granted this is
not something anyone will probably need right now ☺).


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

Ok, these are my points for separation:

• you can update the extensions one by one without affecting the
  unrelated packages (think source package, version number, etc.)
  and have smaller units to work on (although the ftp mirror ad-
  mins might disagree on having more packages)

• probably eases the burden of maintenance on that too…

• you can backport them one by one – especially company users,
  which my use case is, will not be running testing/unstable
  but stuff from backports.org and/or some self-backported pak-
  kages – without the need to backport the rest (and, possibly,
  its dependencies; sharing a source package means you have to
  take them all at the same time)

• debian/copyright is less cluttered (other files probably too)

I can’t think of more right now, and seem to be unable to express
them right, but a coworker makes an analogy with CPAN where you
also don’t have all modules in one single (source and/or binary)
package.

> 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..

Yes, I would like to know one thing:

   You have searched for packages that names contain mediawiki-extensions in all suites, all sections,
   and all architectures. Found 7 matching packages.
                                                                                                            Exact hits                                                                                                                                                                                                              Package mediawiki-extensions
     * [36]etch (oldstable) (web): set of extensions for MediaWiki
       0.1: all
     * [37]etch-m68k (web): set of extensions for MediaWiki
       0.1: all
     * [38]lenny (stable) (web): set of extensions for MediaWiki
       1.4: all
     * [39]lenny-backports (web): set of extensions for MediaWiki
       1.6~bpo50+1 [[40]backports]: all
     * [41]squeeze (testing) (web): Extensions for MediaWiki -- Meta package
       2.2: all
     * [42]sid (unstable) (web): Extensions for MediaWiki -- Meta package
       2.2: all

Why does lenny-bpo have 1.6, and what’s the major change between
the 1.x and 2.x series? This is one of the things keeping me from
even attempting to look at unstable’s mw-extensions package.

Thank you so far for the cooperation and help (also on the
cdbs issue; I must admit I’m somewhat a member of the cdbs-
must-die club we foundet at one of the bugsquashing parties…). 

bye,
//mirabilos
-- 
tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
Geschäftsführer: Boris Esser, Elmar Geese
HRB AG Bonn 5168 - USt-ID (VAT): DE122264941

Heilsbachstraße 24, 53123 Bonn,   Telefon: +49 228 52675-93
Weigandufer 45,     12059 Berlin, Telefon: +49 30 5682943-30
Internet: http://www.tarent.de/ • Telefax: +49 228 52675-25