[Pkg-mediawiki-devel] packaging of MW extensions

[Romain Beauxis]

	Hey !

Le mercredi 23 juin 2010 09:39:45, Thorsten Glaser a écrit :
> 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…

Not in unstable anymore :-)

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

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

Hmmm.... Appart from compatibility with old stables, I do not really see the 
point of having your own standard debian/rules everywhere. Basically, it seems 
to me you are practically doing what cdbs is doing but on a much smaller 
scale, which prevents any benefits of sharing/fixing the same code base with 
many people..

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 
with or without cdbs..

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

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

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

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.

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.

If you look at the xorg situation, I do not think I want to have the same 
overload of work..

> • 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)

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

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

True, indeed.

> 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:
(...)
> 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.

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

Heh :)

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


Romain