Bug#845281: mediawiki: backport version does not play well with extensions
Package: mediawiki Version: 1:1.27.1-2~bpo8+1 Severity: important Quack, If you try to upgrade to the bpo version and you already add mediawiki-extensions installed, the later is to be uninstalled. I understand that the new mediawiki package replaces (and in fact provides) the content of mediawiki-extensions-base now, same for mediawiki-extensions-confirmedit and mediawiki-extensions-geshi, but mediawiki-extensions dragged more packages which are then removed as well. So, it seems to me you package should "Provides" these three packages, in order to play well with mediawiki-extensions. The exact upgrade path needs to be tested. Or you could package a new version of mediawiki-extensions without them and change the minimum requirement in mediawiki. I'll leave finding the best solution to your care. Regards. \_o< -- Marc Dequènes
Bug#845281: mediawiki: backport version does not play well with extensions
Hi, On 11/21/2016 09:55 PM, Marc Dequènes (duck) wrote: > If you try to upgrade to the bpo version and you already add > mediawiki-extensions installed, the later is to be uninstalled. I > understand that the new mediawiki package replaces (and in fact > provides) the content of mediawiki-extensions-base now, same for > mediawiki-extensions-confirmedit and mediawiki-extensions-geshi, but > mediawiki-extensions dragged more packages which are then removed as well. 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. > So, it seems to me you package should "Provides" these three packages, > in order to play well with mediawiki-extensions. The exact upgrade path > needs to be tested. Or you could package a new version of > mediawiki-extensions without them and change the minimum requirement in > mediawiki. I'll leave finding the best solution to your care. 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... -- Kunal signature.asc Description: OpenPGP digital signature
Bug#845281: mediawiki: backport version does not play well with extensions
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
Bug#845281: mediawiki: backport version does not play well with extensions
Hi, On 11/23/2016 11:11 PM, Marc Dequènes (duck) wrote: > 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. Okay, the next version of the package will have a NEWS file (#838965), and but I think apt will still show the removal proposal first? I'll do some testing on that. >> 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. Sorry, I was looking at something else and confused myself. I'll add those Provides for the next version. > 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. Ack. > 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. I understand where you're coming from, but from my point of view, the mediawiki package was removed from jessie because it was so old, and wasn't receiving security support so backporting the 1.27 package provided people a modern version with security support. You're of course totally free not to use the backported version if it will cause trouble for your setup. -- Kunal signature.asc Description: OpenPGP digital signature
