Bug#786657: apache2.4 in jessie/stable missing mod_imagemap
Steven Sumichrast wrote:
> It's been about a year since I last checked on this.
I am not one of the package maintainers. I am just another user.
However I wanted to comment.
> I'm really not sure what the method to proceed here is -- am I going
> to have to custom build my own package for Apache when we move to
> Debian Jessie?
I think you have two options if you want imagemap in your next upgrade
in your environment. 1) Package it yourself for your own use in
Jessie. 2) Address the problem in Sid for the next release Stretch.
Wait for Stretch to release. Upgrade to Jessie and then immediately
upgrade to Stretch basically skipping Jessie entirely. (You must
go through Jessie however. Can't skip stopping there once.)
The reasoning being that Jessie has already released without support
for imagemap. It is too late to change it now. Debian isn't a
rolling package model. Debian makes releases about every two years.
Once released the version that was released is only updated for major
problems and security upgrades. (A simplified description.) This
release model is one of the things that users such as myself rely
upon. I know that a release won't be modified and break something out
from under me after it has been released.
This feature doesn't seem to qualify as a potential update candidate.
Therefore the earliest this could be changed would be in the next
release in Debian Stretch. Which means it would need to go into Sid
first since Sid is always the development area for the next release.
However this feature is marked obsolescent by upstream and removed
from upstream. That makes it a hard sell for continuing support. I
think it would be difficult to argue that it needs to be in Stretch.
Therefore supporting it yourself may be the only option. That has
happened to me on ocassion when I am using something that isn't
generally in use elsewhere. I just have to do it myself in those
cases. I think that may be the case here too.
Really the time to find out if something changes in a release that
breaks something we as users care about is *before* it gets released.
And so it means I suggest testing out Testing before release and
reporting anything that does cause problems as bugs before it is
released. Because after it is released is too late.
I don't run Testing or Unstable on my production machines but I do run
victim testing systems (mostly VMs) running Unstable that run in
parallel to my production machines. I run routine testing against
them. If something breaks in Unstable I can find it there and submit
bugs and prevent the change from moving automatically into Testing.
Most of the time these can run for months with no problem.
But sometimes it can mean a lot of work on my part scrambling around
trying to keep the systems in a happy state. It isn't free. I see it
as the cost of using a libre community supported distribution. It
isn't without cost but the cost is some effort on my part to
participate in the process. (Rather like politics, actually.) Doing
this means I can avoid surprises in the next Stable release. (However
even doing this some things slip through and I just have to live with
it for the next two years until the next release. I am looking at you
emacs!)
> Steven Sumichrast wrote:
> > The site using these server-side maps probably has hundreds of them in
> > use. Converting them to user maps is going to be a significant chore.
> > While I can probably provide the guidance and suggestion to do so, I can't
> > say that will be done in any short order, so for the interim yes the module
> > is required.
Wheezy has moved to the LTS support mode. It will be good for some
time yet. You have time to deal with the issue slowly.
Bob
Reply to: