Thinking about it some more, I think I will use this 3-step approach. We've already got a "libpetsc-dev" in the form of petsc-dev (ought we to change that?). What I'll do is add the middle libpetsc3.6-dev package.
Drew On Tue, 2016-03-15 at 20:43 +0200, Jan Groenewald wrote: > I think it sounds good and I've seen before > > libpetsc-dev -> depend on latest libpetsc3.6-dev > libpetsc3.6-dev-> depend on latest lbpetsc3.6.x-dev > > Users install libpetsc-dev and get the latest, and devs and some > users can try other versions to test/compare. > > Regards, > Jan > > > > On 15 March 2016 at 19:43, Graham Inggs <[email protected]> wrote: > > On 15 March 2016 at 12:14, Drew Parsons <[email protected]> > > wrote: > > > But I'm not certain that anything is gained by having parallel > > > installations for a library with the same soname. It could be > > done, > > > e.g. libpetsc3.6-dev could be a virtual package that depends on > > the > > > latest libpetsc3.6.x-dev. But would that provide any real > > benefit? It > > > seems to me that using libpetsc3.6-dev as the dev package would > > be > > > simpler. > > > > Why not simply libpetsc-dev? > > > > > >
