Re: concurrent installation of different pkg versions
On 30/04/14 03:45, Thomas Goirand wrote:
> On 04/26/2014 01:39 AM, Daniel Pocock wrote:
>>
>> With all the talk about removing jquery from source packages, one thing
>> that does arise is the question of how to support different jquery versions.
>>
>> This is not just a JavaScript issue though. Maybe we can have
>>
>> libjs-jquery-1.7
>> libjs-jquery-1.10
> There's nothing that prevents us from manually deciding to have
> different versions installed at once: this is a packaging decision. We
> could have for example:
>
> >From package libjs-jquery-1.7:
> /usr/share/javascript/jquery/1.7
>
> >From package libjs-jquery-1.10:
> /usr/share/javascript/jquery/1.10
>
> This is the exact same thing that happens with .so libraries, and this
> should happen *only* when there's an API change (why would you want to
> keep an older version otherwise?).
>
> I strongly believe that this should be avoided as much as possible (for
> example with good communication with upstream so that they understand
> the needs of distributions), though there's some cases where probably
> it's impossible. I wouldn't like if we were generalizing the practice,
> but would understand and feel reasonable if we had a few cases of it,
> for example let's say 2 jquery versions at once max on a give system.
This is still something that keeps coming up for me. I gave jQuery as
an example because it is so common but the more specific cases I am
thinking about involve applications that share a database and must run
an application version that matches the schema version.
I'm currently thinking that the postbooks packages will start to be
named postbooks-4.7, postbooks-4.8 etc and will install concurrently.
In a single instance of PostgreSQL, a user may have different schemas
for different versions of postbooks. This type of scenario is
particularly common in support and development environments for such
software or for people who are testing a new version.
>From what I can see, this already happens for:
- shared libraries (ABI version in package name)
- PostgreSQL servers (e.g. the package name postgresql-9.4 from jessie
installs concurrently with postgresql-9.1)
- gcc (e.g. gcc-4.6, gcc-4.7 installed concurrently)
I made a search for documentation about this package naming/versioning
strategy and while there are details for shared libraries I couldn't
find anything about the more general case. Can anybody make any more
specific comment about this or suggest other documents that cover this
topic?
Reply to: