After thinking about this for a few days, it seems to me reasonable to request a FESCo call on it.
Here's the story so far.
There are currently two actively-maintained major release series of ImageMagick, 6 and 7. ImageMagick versioning is a little weird; they version W.X.Y patchlevel Z, where any change to W, X or Y usually involves an soname bump, but changes to Z (the 'patchlevel') do not. In Fedora's packages, we set the version as 'W.X.Y.Z'.
There are fairly significant API incompatibilities between the 6 and 7 series. Many of them are described on this Porting page.
Our ImageMagick package was not very actively maintained for some time, and Moez Roy noticed this (and that it was vulnerable to a large number of publicly-disclosed security vulnerabilities, several of which are collectively known as 'ImageTragick').
He activated the non-responsive maintainer process for it and eventually took the package over. Meanwhile, the situation was discussed on devel@, and @kevin built the then-latest release in the ImageMagick 6 series (6.9.9.3, that is, 6.9.9 patchlevel 3) for Rawhide. This was an update from 6.9.3.0 (6.9.3 patchlevel 0), so resulted in an soname change. @kevin rebuilt most dependent packages against it. He then apparently intended to wait a while and see if any problems were reported in Rawhide / F27 before doing the same 6.9.3.0 -> 6.9.9.3 update and rebuilds for Fedora 25 / 26.
However, before @kevin went ahead with that plan, Moez took ownership of the package and, if I'm reading his email correctly, figured "since dependent packages would need rebuilding for an update to 6.9.9 anyway, let's just update to 7.0.6 instead". He built 7.0.6 for all active branches (Rawhide, F27, F26, F25) and sent it out as an update for F25 and F26, but did no work on rebuilding dependent packages.
The F25 and F26 updates were killed by negative karma and never reached stable; Michael Cronenworth and myself have subsequently sent out replacement updates to 6.9.9.9 (6.9.9 patchlevel 9) with rebuilds of all dependent packages.
However, as things stand, in Fedora 27 and Rawhide, we still have 7.0.6 but with many broken dependencies. Michael has volunteered to work on the rebuilds, but I am concerned especially for Fedora 27 that this bump to version 7 is fundamentally a bad idea.
I looked at several of the dependent packages while doing the F25 / F26 rebuilds for 6.9.9.9, and noticed that none of the ones I looked at were already compatible with ImageMagick 7, nor were there upstreamable patches that I could find. For some packages I could find patches that at least made the code build against 7, but they usually broke compatibility with 6 (thus unlikely to be accepted upstream) and didn't usually seem to have been tested very hard. I thus suspect that quite a lot of work will be involved in rebuilding all the dependencies, and we may well wind up with non-upstreamable patches and perhaps with code that builds but doesn't work fully.
It's also worth noting that ImageMagick is very commonly used via invocation of its executable (either interactively or scripted), and ImageMagick 7 changes the 'API' for this in many ways as well. For a start, the actual command name is different; in ImageMagick 6 it was convert, in ImageMagick 7 it's magick. There have been various changes to the available subcommands and arguments, as well. It seems highly likely that many scripts that rely on the naming and behaviour of ImageMagick 6 will just not work with ImageMagick 7.
convert
magick
Finally I'll note that we are 11 days away from the Fedora 27 Beta freeze (with Flock in the middle there), and this change has not run through the Change process at all.
Given all these concerns, I'm not at all convinced that it's appropriate to rush a jump to ImageMagick 7 into Fedora 27. I suggest we consider the alternative of reverting to 6.9.9.9 for F27 (unfortunately, this will involve an epoch bump, as a compose with 7.0.6 has now made it to the wild) and only going to 7 in Rawhide (or even reverting Rawhide too for now, and proposing ImageMagick 7 as a Fedora 28 Change so it can be properly considered, and only actually re-doing the bump to 7 if the Change is accepted).
Thanks for your consideration!
To be clear on the 6 vs. 7 difference: while going from 6.9.3 to 6.9.9 caused an soname bump and required dependencies to be rebuilt, it didn't really involve any significant API changes, and all the dependencies rebuilt just fine with no modifications needed. Similarly they don't make major changes to the CLI in 6.x releases. The difference between 6.x and 7.x is far far bigger than the difference between 6.9.x releases.
ImageMagick versioning is a little weird; they version W.X.Y patchlevel Z, where any change to W, X or Y usually involves an soname bump, but changes to Z (the 'patchlevel') do not.
Upstream have already bump soname in a patch release, for memory:
The difference between 6.x and 7.x is far far bigger than the difference between 6.9.x releases.
IM 7 also switch to HDRI by default.
I suggest we consider the alternative of reverting to 6.9.9.9 for F27 (unfortunately, this will involve an soname bump
Of course you mean an "epoch" bump..
BTW, despite I don't like epoch bump, I think reverting to IM 6 everywhere is the safest way.
fixed the soname/epoch thinko, thanks.
Honestly, I would ask maintainer of IM to fix affected packages. If this can't be done quickly in F27, I would propose to revert to 6.x in F27.. Rawhide probably could stay on 7.x, depending how many packages it breaks (e.g. workstation image).
Is it possible for us to ship both ImageMagick 6 and ImageMagick 7? Are they fully parallel installable?
If they are parallel installable, and especially if upstream actively maintains both branches at the same time, it might make sense for us in Fedora to ship both versions as well. Then individual packages (and scripts that use convert/magick command etc) can be ported when they are ready.
@kalev: I haven't checked, but I'd agree it's an option worth considering.
My proposal: I'm firmly opposed to allowing ImageMagick 7 as the sole version in F27. If it's desired for F28, please submit it as a system-wide Change proposal ASAP.
If it can be parallel-installed, I'm okay with doing so under the proviso that no content shipped in the default install of any blocking F27 media may require ImageMagick 7. In other words, important software must not update to ImageMagick 7 prior to F28.
Metadata Update from @jforbes: - Issue tagged with: meeting
#agreed sgallagh's proposal in ticket is accepted (+8,0,-0)
Metadata Update from @jforbes: - Issue untagged with: meeting - Issue status updated to: Closed (was: Open)
I will work on the epoch bump + downgrade + dependent rebuilds either over the weekend or on Monday (depending on post-Flock energy levels...)
As state in devel mailing list we may and should have IM 6 and 7 in same version
Based on the response from ImageMagick [1] let's rebuild for version 6 in F27+. We should keep 7, but as ImageMagick7 instead.
[1] https://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=32622&p=149403
Well if we go to have ImageMagick6 and ImageMagick7 in F27+ and since ImageMagick7 should be the main package, in my point of view , we should add ImageMagick6 package and maintain ImageMagick as is , like, for example, openssl-1.1 and compat-openssl10 .
That's just the opposite of what FESCo decided on...
Just to make things more funny:
yes
yes , but since then we got new information ...
What new information?
can be parallel-installed and IM 6 will be around many time
FESCo already considered the possibility that they could be parallel installed and explicitly mentioned it in their discussion (i.e. deciding that it was fine, but IM 6 must be the main package and IM 7 the explicitly-versioned alternative). And we already knew IM 6 was going to be maintained upstream for a while too. So, I don't think either of those would change FESCo's decision.
OK , I will wait for new releases
I mean I will wait for the new packages Thanks
To be entirely clear: we voted that the effective outcome for F27 is that nothing "important" (see above for definition) may depend on IM7. IM7 may be added to the F27 repository as long as they have different names.
Just to muddy the waters, we didn't rule on which version gets to have the unversioned name (ImageMagick vs. ImageMagickN). If the maintainers of the package feel that there will be a big switch over to IM7 in Fedora 28, it makes sense (to me, at least) to allow them to claim the unversioned name at that time.
So, in the interest of not wasting effort, it may be worthwhile to put IM7 only in Fedora 28 and create a compat- package for IM6 at that time, rather than creating an ImageMagick7 package right now that will be retired in one release. But I'm fine with leaving that decision to the maintainers.
However, before any of the F28 work happens, I'd like to see the ImageMagick maintainers figure the ultimate state out for themselves and submit a Change Proposal to FESCo so that we can validate it.
I don't think anyone working on IM is super keen on pushing 7 at all any more, at this point :P We agreed on devel@ to just go ahead and downgrade to 6 with an epoch bump in both 27 and 28. I'll be working on that today (hoped to get it done over the weekend or on Monday, but it didn't happen).
I have done rebuilds of IM and all (I hope) dependencies for Rawhide and F27, and submitted an update and a freeze exception-nominated bug for F27:
Could this be reconsidered for F34?
what you mean by "this" ?
Downgrading back to ImageMagick 6 (can we upgrade to 7 now?)
ImageMagick 7 is still not available in Fedora.
I will provide it , in next weeks , after other updates in ImageMagick I will do a new package: ImageMagick7 etc
Login to comment on this ticket.