Bug#1060103: transition: imagemagick7
Hi Bastien, On 02/06/2024 14:38, Bastien Roucariès wrote: Le dimanche 2 juin 2024, 11:17:33 UTC Sebastian Ramacher a écrit : On 2024-02-02 17:21:43 +, Bastien Roucariès wrote: Le vendredi 2 février 2024, 16:53:10 UTC Sebastian Ramacher a écrit : Control: tags -1 moreinfo Hi Bastien On 2024-01-05 22:35:44 +, Bastien Roucariès wrote: Package: release.debian.org Severity: important User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: ftpmas...@debian.org Imagemagick will need a new major bump I achieved to get imagemagick 7 build for experimental (it is only on salsa not uploaded yet). Every package include a version in the package name (except legacy package name and perl*) so I plan to do some step by step migration, because it is mainly coinstallable with imagemagick 6. Why does this migration require co-instabillity with the old version? This makes the transition overly complicated. Do you expect major changes required in reverse dependencies of imagemagick's shared library? The problem is not the library but the command line interface that may need change. Librarry will break (I think here about php module that will need a update), but it is treatable. convert6 is not fully compatible with convert7 convert6 will be co installable with convert7 in order to test, and convert will be provided by alternative system. If they are not fully compatible, then alternatives are not an option. They are 95% compatible How many packages are we talking about? Have bugs been filed for packages thar are not compatible with convert7? The problem is chicken and eggs problem. If you could not test then you could not report bug. A least both should be in experimental for running a full archive rebuild Not really. I also don't think the 3-step migration plan in experimental you're proposing makes much sense. What we need here is to know how many packages fail to build against imagemagick 7. And for that, the package doesn't even need to be in experimental. Also, you don't need to perform a full archive rebuild, just rebuilding those packages that build-depend on imagemagick would be enough. Once that is done and we're ready to go, after going through experimental as src:imagemagick (no renamed package), then we would start the transition and scheduled the necessary binNMUs, and raise any bugs to serious. That'd be the ideal scenario. But we don't know how feasible that is until we know how many packages will need source changes, and for that we need the results of the test rebuilds. Cheers, Emilio
Bug#1060103: transition: imagemagick7
Le dimanche 2 juin 2024, 11:17:33 UTC Sebastian Ramacher a écrit : > On 2024-02-02 17:21:43 +, Bastien Roucariès wrote: > > Le vendredi 2 février 2024, 16:53:10 UTC Sebastian Ramacher a écrit : > > > Control: tags -1 moreinfo > > > > > > Hi Bastien > > > > > > On 2024-01-05 22:35:44 +, Bastien Roucariès wrote: > > > > Package: release.debian.org > > > > Severity: important > > > > User: release.debian@packages.debian.org > > > > Usertags: transition > > > > X-Debbugs-CC: ftpmas...@debian.org > > > > > > > > Imagemagick will need a new major bump > > > > > > > > I achieved to get imagemagick 7 build for experimental (it is only on > > > > salsa not > > > > uploaded yet). > > > > > > > > Every package include a version in the package name (except legacy > > > > package name > > > > and perl*) so I plan to do some step by step migration, because it is > > > > mainly > > > > coinstallable with imagemagick 6. > > > > > > Why does this migration require co-instabillity with the old version? > > > This makes the transition overly complicated. Do you expect major > > > changes required in reverse dependencies of imagemagick's shared > > > library? > > > > The problem is not the library but the command line interface that may need > > change. > > > > Librarry will break (I think here about php module that will need a > > update), but it is treatable. > > > > convert6 is not fully compatible with convert7 > > > > convert6 will be co installable with convert7 in order to test, and convert > > will be provided by alternative system. > > If they are not fully compatible, then alternatives are not an option. They are 95% compatible > How many packages are we talking about? Have bugs been filed for > packages thar are not compatible with convert7? The problem is chicken and eggs problem. If you could not test then you could not report bug. A least both should be in experimental for running a full archive rebuild Not also that imagemagick6 is supported upstream only until 2027... So we should migrate to 7. That why I think my way is a good way. Suse and redhat transitionned see https://fedoraproject.org/wiki/Changes/ImageMagick7 Discussion point to a least broken on redhat * autotrace - plan to notify upstream * dvdauthor - point to GraphicsMagick or IM6, plan to notify upstream * q - dead upstream, planned to point to IM6 * vdr-skinnopacity - current upstream dead, plan to notify new upstream * vdr-tvguide - plan to notify upstream We could also drop imagemagick6 and use graphickmagick if needed but it introduce other problem Thanks Bastien > > Cheers > signature.asc Description: This is a digitally signed message part.
Bug#1060103: transition: imagemagick7
On 2024-02-02 17:21:43 +, Bastien Roucariès wrote: > Le vendredi 2 février 2024, 16:53:10 UTC Sebastian Ramacher a écrit : > > Control: tags -1 moreinfo > > > > Hi Bastien > > > > On 2024-01-05 22:35:44 +, Bastien Roucariès wrote: > > > Package: release.debian.org > > > Severity: important > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > X-Debbugs-CC: ftpmas...@debian.org > > > > > > Imagemagick will need a new major bump > > > > > > I achieved to get imagemagick 7 build for experimental (it is only on > > > salsa not > > > uploaded yet). > > > > > > Every package include a version in the package name (except legacy > > > package name > > > and perl*) so I plan to do some step by step migration, because it is > > > mainly > > > coinstallable with imagemagick 6. > > > > Why does this migration require co-instabillity with the old version? > > This makes the transition overly complicated. Do you expect major > > changes required in reverse dependencies of imagemagick's shared > > library? > > The problem is not the library but the command line interface that may need > change. > > Librarry will break (I think here about php module that will need a update), > but it is treatable. > > convert6 is not fully compatible with convert7 > > convert6 will be co installable with convert7 in order to test, and convert > will be provided by alternative system. If they are not fully compatible, then alternatives are not an option. How many packages are we talking about? Have bugs been filed for packages thar are not compatible with convert7? Cheers -- Sebastian Ramacher
Bug#1060103: transition: imagemagick7
Le vendredi 2 février 2024, 16:53:10 UTC Sebastian Ramacher a écrit : > Control: tags -1 moreinfo > > Hi Bastien > > On 2024-01-05 22:35:44 +, Bastien Roucariès wrote: > > Package: release.debian.org > > Severity: important > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-CC: ftpmas...@debian.org > > > > Imagemagick will need a new major bump > > > > I achieved to get imagemagick 7 build for experimental (it is only on salsa > > not > > uploaded yet). > > > > Every package include a version in the package name (except legacy package > > name > > and perl*) so I plan to do some step by step migration, because it is mainly > > coinstallable with imagemagick 6. > > Why does this migration require co-instabillity with the old version? > This makes the transition overly complicated. Do you expect major > changes required in reverse dependencies of imagemagick's shared > library? The problem is not the library but the command line interface that may need change. Librarry will break (I think here about php module that will need a update), but it is treatable. convert6 is not fully compatible with convert7 convert6 will be co installable with convert7 in order to test, and convert will be provided by alternative system. We avoid a flag day, but we need co installable library. Bastien > > PS: Before the time_t transition is done, we will not process other > transitions. Not a problem, but I will like to upload work on experimental in order to test other arch than i386/amd64/arm that I could test Bastien > > Cheers > signature.asc Description: This is a digitally signed message part.
Bug#1060103: transition: imagemagick7
Control: tags -1 moreinfo Hi Bastien On 2024-01-05 22:35:44 +, Bastien Roucariès wrote: > Package: release.debian.org > Severity: important > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-CC: ftpmas...@debian.org > > Imagemagick will need a new major bump > > I achieved to get imagemagick 7 build for experimental (it is only on salsa > not > uploaded yet). > > Every package include a version in the package name (except legacy package > name > and perl*) so I plan to do some step by step migration, because it is mainly > coinstallable with imagemagick 6. Why does this migration require co-instabillity with the old version? This makes the transition overly complicated. Do you expect major changes required in reverse dependencies of imagemagick's shared library? PS: Before the time_t transition is done, we will not process other transitions. Cheers -- Sebastian Ramacher
Bug#1060103: transition: imagemagick7
Package: release.debian.org Severity: important User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: ftpmas...@debian.org Imagemagick will need a new major bump I achieved to get imagemagick 7 build for experimental (it is only on salsa not uploaded yet). Every package include a version in the package name (except legacy package name and perl*) so I plan to do some step by step migration, because it is mainly coinstallable with imagemagick 6. - upload to experimental a version with perl and without legacy name - migrate perl and versioned package - add to experimental libmakickgwand-dev libmagick++-dev libmagickcore-dev - migrate package that depends on libmakickgwand-dev libmagick++-dev libmagickcore-dev (every thing that build against imagemagick) to imagemagick7 - add to experimental imagemagick package - migrate imagemagick package to unstable What do you think of this plan ? From a security point of view it is better to go to imagemagick7 (so important severity) I expect breakage only on the last step. See https://imagemagick.org/script/porting.php ftpmaster it need more work because it will need three manual step. Bastien * perlmagick, libmagickcore-dev, libmakickgwand-dev libmagick++-dev, imagemagick, libimage-magick-perl libimage-magick-q16-perl libimage- magick-q16hdri-perl signature.asc Description: This is a digitally signed message part.
