Quack,
On 2016-11-24 14:41, Kunal Mehta wrote:
This is somewhat intentional as the new package only contains some of
those packages (those that are shipped by upstream as part of the
tarball), while the mediawiki-extensions-base package was a somewhat
arbitrary list of extensions.
I understand, but when I saw the APT proposal, I quickly said NO to
avoid breakage, but still had no clue what to do.
The package already has provides for those three packages (base, geshi,
and confirmedit), but I think it will still need to break
mediawiki-extensions since none of the extensions in that package are
compatible with the newer version and not all of them are provided by
the new package. I also have no plans on updating the
mediawiki-extensions-* packages. So I'm not sure really what other
steps
can be taken...
Which package has these provides? mediawiki does not,
mediawiki-extensions does not either, I just checked again.
IMHO, removing the mediawiki-extensions package & co in unstable, with a
NEWS.Debian explaining the situation in the mediawiki package, is fine
for the next release. The user can review its extensions, packaged or
not; it is part of the machine's planned upgrade to switch release, so
no big issue here.
As for bpo, this is much different. bpo are here to provide a
convenience upgrade for some specific package, but is not meant to be a
major disruption. If you leave the users without any upgrade path, then
this is not nice. As you do not plan to support packaged extensions,
then probably you should not have proposed a backport in the first
place. In this case, to avoid surprise, I think using debconf and
cancelling install in preinst would be better.
You may also ask for more advice on mailing-lists.
Hope this was helpful.
Regards.
\_o<
--
Marc Dequènes
