Re: Versionned dependencies
On Thu, Feb 2, 2012 at 10:54, Tanguy Ortolo <tanguy+debian@ortolo.eu> wrote:
> ¹ Technically, it could be expressed by expanding it according to de
> Morgan's laws, but the result would be a huge and complicated
> dependency list, which would probably give a hard time to dependency
> solvers.
Technically, our dependency solvers would end up creating this huge and
complicated "on the fly" to not break everything.
It would be at least what i would do for APT as this "small change" could
easily end up creating more source-changes than multiarch did otherwise.
(In all frontends, not just libapt)
You then only have to tell everyone else parsing dependencies to do this, too,
and release it with $release (which is with the current adoption rate of
multiarch in tools you would need to change, too, something around wheezy+2).
Wait for $release+2 so that at $release users are able to upgrade to
$release+1 and here you are at wheezy+4 and able to use it - in theory.
(my personal offtopic bet: Browser major-versionnumbers will no longer fit
into 8bit at that time)
Or you write a (optionally debhelper) script which generates the huge
dependency line for you in $release - in theory.
In practice you properly will hit bugs in both ways, so lets add at least one
release to squeeze them out.
BUT somehow all this feels a bit wrong. It's not really the extension
depending on a lower version of iceweasel and co, its just iceweasel
breaking extensions with newer versions (maybe) and therefore extensions
shipping a file telling iceweasel that it was only tested up to this version.
Your multi-version dependency has still the problem that i could install an
extension which will happily work with the installed iceweasel, but not with
the installed iceape as it has the wrong version, but the or-group is
satisfied. So it still depends on the fact that the xul-applications detects
"old" extensions and therefore i would just "ignore" the upper limit as it
can't be really enforced by the package manager as it will never know if the
extension was installed for usage in A, B or both…
Stable users shouldn't really be effected by this at all and unstable/testing
users should be able to handle this. Then there would be even a use for the
"ignore version requirements" feature in iceweasel and co, as most extensions
aren't as frequently updated as iceweasel just to increase versionnumbers…
(For a bit of tool support you could recommend << versions though.)
Best regards
David Kalnischkies
Reply to: