Re: concurrent installation of different pkg versions
On 28/04/14 21:16, Jonas Smedegaard wrote:
> Quoting Daniel Pocock (2014-04-28 20:10:09)
>> On 28/04/14 18:59, Gunnar Wolf wrote:
>>> Paul Wise dijo [Sat, Apr 26, 2014 at 11:41:17AM +0800]:
>>>>> a generalized approach is needed.
>>>> Multiple versions of a package seems undesirable to me, for the
>>>> same reasons as static libraries and embedded code copies are
>>>> undesirable.
>>> [...] It makes sense for a programmer [...]
>>> But supporting this as a whole is a mess.
>> I'm not suggesting that this is a practice that should be encouraged
>> nor given the same level of security support in every case.
>>
>> However, there are cases (e.g. hundreds of packages containing jquery)
>> where it becomes the lesser evil: instead of having hundreds of copies
>> of non-standard JavaScript dependencies, we end up with maybe 3 or 4
>> supported versions of each important library.
> What level of support _are_ you talking about - at all?
>
> I fail to understand: How are packages magically "supported" by it being
> possible to co-install both the version maintained ordinarily and older
> instances of same package no longer maintained but e.g. fetched from
> snapshot.d.o?
>
> If you imply support from the security team for snapshot.d.o then I find
> it quite important to state explicitly what you have in mind.
>
> If you imply support from the package maintainer, then I find it more
> sensible to simply maintain as separate packages for each "branch" that
> the maintainer deem sensible to support - as we are doing with a range
> of packages.
>
> If you don't really mean "supported", just "possible" then there are
> several ways a sysadmin can either maintain a separate virtualized full
> Debian installations or a custom versions of code (possibly simplest
> being to pile stuff up below /usr/local or withing the project needing
> it).
Perhaps the support burden for legacy versions should be taken up by
those people packaging things that depend on the legacy versions.
They would then have to weigh up the benefits of getting upstream to
work with newer jquery or supporting a legacy jquery package.
Reply to: