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). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature