[Pkg-mediawiki-devel] packaging of MW extensions

[Thorsten Glaser]

On Wed, 23 Jun 2010, Romain Beauxis wrote:

> > php-openid? mediawiki-extensions depends on it…
> 
> Not in unstable anymore :-)

Ah, ok.

> Also, the files layout has greatly changed in unstable. Now adding an extension 
> should mimick exactly what is done without a package. I would highly recommend 
> starting with this package..

OK, I would revisit mine then.

> Hmmm.... Appart from compatibility with old stables, I do not really see the 
> point of having your own standard debian/rules everywhere.

Yeah, it’s just a thing I do in order to create Debian source packages,
which is a process complicated enough… I just always copy a working one
as template into the new one. My way to deal with this complexity.

> The backward compatibility is one argument but I do not think it should be the 
> only one. For instance, you may use new debhelpers, which would prevent this 

Well, I wouldn’t ☺

> Also cdbs is available in lenny and etch, which way enough to my opinion. 
> Since we do not use advanced features, the packaging should also work there..

Sure.

> Hence, I wonder: what do you think is a problem with cdbs ?

Just another weird thing, difficult to understand its inner workings,
and full of bugs. I’ve had contact with it as NMUer (especially when
fixing the recent libtool security stuff). Probably doesn’t apply to
the MW packages.

> I am not convinced by those two points. First, having a seperate source and 
> binary package for extensions that are only few ko is ridiculous and will mean 
> waiting in NEW a lot.

That’s true (although one of my coworkers is on the ftpmaster team).

> Also, the burden of maintenance, to me, is much more simple if I can update 
> all the extensions by one call to the update script. Otherwise, it needs a 
> proper attention for each package.

OK. Do you really do that?

> That's a good point. However, I do not think that backporting should be the 
> main purpose of packaging but rather preparing the next stable. This also 
> relates to the issue with backward compatibility..

You have a point there, but please understand I’m doing this on company
time, and as such I cannot care about the *next* stable (which we’ll
probably be using no earlier than 6-9 months after its release anyway,
you know how this works, we still have 2 dapper, 1 sargs and a number
of etch systems). Of course this shall not affect my dealing with any
packages, but it does affect the main point of view.

> > 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.
> 
> Lack of time, simply.

Ah okay. So if I were to tackle the package from unstable, add all
the plugins I need, make an 2.2test1 out of that, I could build and
install it on lenny unmodifiedly?

> Well, I hope our divergences in technical aspects will not prevent us from 
> working on this package :-)
> 
> Let me know what you think of the update script..

If the above is the case, I think I can abandon my packages and
the PPA packages and throw all of it into yours. Grudgingly, but
for the sake of better cooperation with you, less work for all
of us (I assume you’ll be taking care of the extensions I add
when you do your regular upgrades, and I’ll test most of the
stuff anyway, and Gabriel can probably just rebuild the packages
for his systems too), I see the benefits.

Merci,
//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