Comment 30 for bug 53856

We should really try to sort this out, and not just to have a good solution on dapper but also to prevent problems like this from happening again (what if clamav 1.00 breaks API with 0.90 while 0.90 is in the next 'LTS'?). Also, I think a problem like this could arise for other packages as well.

I'm already using lots of virtual machines (xen domU) with dapper, so count on me for whatever testing is needed. It takes me 5 minutes to bring up a new dapper system, install, test, delete the system :)

So, if I understood correctly, this is our situation:
- some form of upgrade to clamav in Dapper is really desired and also coherent with the 'LTS' / 'server' release idea.
- can't backport from more recent versions of clamav (which we have in more recent versions of ubuntu) since it changed API. This is against backport policy rule 3 ('New versions can be backported, when they're already compatible with OS and system-relevant libraries.'), rule 4 ('No new libraries which will "break" or affect other applications (e.g. libvorbis, libz, etc.) unless the update fixes an exploit.') and also against good, common sense.
- can't backport from an hypotetical 0.80.x branch with newer scanning engine since we don't have a port to backport from - see backport policy rule 1 ('Only packages currently in Ubuntu's development branches are eligible for backporting').

I'm assuming the official policy is the one at https://help.ubuntu.com/community/UbuntuBackports. Possible solutions:
 * find a way to backport a 0.90.x version and make it coexist with the current system.
Eg., call it clamav090 so apps that use 'clamav' do not get disturbed - or whatever (portage slots come in handy in this kind of situations on gentoo. don't know if the portage guys found a way to make clamav 0.80.x and 0.90.x coexist as two different slots, maybe it's worth a look). This way we could have the desired scanning engine on the system, to be used through clamd or similar interfaces (that do not suffer the API change problem). I don't know if this is acceptable with ubuntu policies and/or actually possible to do.
 * get the new scanning engine on 0.80.x, get the new 0.80.x in a in-development ubuntu (same problems as previous case to make 0.80 and 0.90 coexist since we have 0.90 in newer versions of ubuntu) and backport. Apps on newer ubuntu will link (and depend) on 0.90.x and apps on dapper link (and depend) on 0.80.x, so they'll just ignore the backport while anything that dosn't suffer the API problem will be able to use it (basically anything the interfaces to clam through one of its processes and not through calls to its libs).
 * get the new scanning engine on 0.80.x and find a way to put it in dapper without putting it in newer ubuntu releases. No issues with 0.80 and 0.90 on the same system, but we need to change backports policy or find an acceptable trick to get around it.

What do you guys think? Is any one of those possible and worth trying? Do you have any other solution to propose?

Some final points I'd like to stress:
- this is really a critical problem with clamav on dapper
- this could apply to later releases of ubuntu (see the clamav 0.90 -> 1.00 example in the beginning)
- this could apply to other packages in current or future ubuntu releases (on one of my systems I stumbled upon bug #49170 which could be a similar one - need to investigate further), so a good 'generic' solution to similar problems should be found. Any long-term-support release will suffer similar problems sooner or later: while software gets updated some of those (not bugfix) updates will be realle desiderable or actually required for an LTS release to make sense and be worth using.
- the solutions involving the newer engine on 0.80.x depend on upstream, but even without upstream collaboration we should sort this out for ubuntu in case of future problems with this or other packages (see the previous points).