[php-maint] Re: bringing existing seperately packaged on-tree modules into main source package?

[sean finney]

hey steve,

On Sat, 2006-11-11 at 22:24 -0800, Steve Langasek wrote:
> Isn't it the responsibility of the maintainers of those individual module
> packages to do this?  The whole reason most of these were split off in the

well ideally, yeah... but it seems like the maintainers of those
packages are also the same as the php package maintainers.  given that
of those maintainers, only 2 have been making significant contributions
in the past couple months...

> source package because of a) library entanglement problems, b)
> updating/building all of php4 and/or php5 in response to a bugfix for a
> particular extension is an inefficient use of the buildds and doesn't allow
> very well for parallelization of maintenance, c) many extensions are now
> available in PECL in a form suitable for building against both php4 and
> php5, providing better package consistency than what we get if each of php4
> and php5 are building a different in-tree version.

i don't see (a) really being a significant issue, and (b) sucks but it
wouldn't be the end of the world since hey, when are there ever security
issues with php? :)  about (c), i think that makes sense if the
underlying code is the same (or at least compatible) in both trees.

> I think the bundling of all extensions in a single source package is yet
> another example of PHP upstream's incompetence, and we shouldn't necessarily
> follow their ill-informed example just because we're saddled with copies of
> all of these modules in the source package.  Actually, now that there's no
> need to edit php.ini for modules, there's no need for debconf templates or
> updates, which makes it even easier than ever to maintain modules out of
> tree..

"easier than ever" for a distributed group of people working in
parallel, yes.  but if the people responsible for those packages are the
same subset of active maintainers for php, it makes things more
difficult because the same thing has to be done over and over again by
the same person.  given the level of activity of the other members,
i'm wondering if it will even get done unless ondrej or i do it.

> > additionally, each of these modules are currently uninstallable from
> > unstable, because of a phpapi change in 5.2.0, so they need to be
> > rebuilt and uploaded.
> 
> Well, if people weren't being clever and giving binary packages different
> version numbers from their source, these would be binNMUed already :P

i saw you mention something about this earlier, though i don't know the
background and what exactly the problem is.  what should the Version:'s
be set to?

> That's true that they won't get php stuck in NEW, though it will definitely
> get php entangled more frequently in library transitions.

this is a double-edged sword really.  if some other library transition
is going on, a single source packaged php "suite" would get stalled.
but if we don't have a single source packaged suite, every time the
phpapi gets bumped we create another library transition for all the
php modules.



	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20061112/1b94787c/attachment.pgp