Re: packaging guide questions

[Junichi Uekawa <dancer@netfort.gr.jp>]

Hi, 

adding debian-mentors, you may get a lot more response there to your question.


At Sat, 30 May 2009 01:39:00 +0100,
Stanisław Pitucha wrote:
> 
> Hi,
> I've got two questions I couldn't find answer to... (at least in the
> official guide). Could you answer them / point me at the correct
> mailing list?
> 
> If there is a source package which generates: a common library
> everything else is linking against, 2 binaries, many plugins (common
> and specific):
> 
> 1.
> Is there a way to make plugins depend on the specific verison of the
> program, but allow for minor corrections? I.e. if everything is in
> version 1.2.3 of the app, but some plugin needs a minor correction
> that doesn't require rebuilding main binary packages / the common
> library, then is there a way to set version dependencies in such way
> that the plugin can be updated separately?

I think you could use, for example, ${Source-Version} dependency here,
but I doubt it will always work (for example, you have to use
different notations for new incompatible compiler changes etc.)
and makes it harder for security fixes etc. to happen.

> 2.
> If it's highly unlikely anyone will ever use the common library
> without installing the binary programs, is there any reason to keep it
> separate? There has to be a -dev package, but creating something like:
> - prog-binary-A, prog-binary-B
> - libprog, prog-dev
> - prog-plugins, prog-plugin-mysql, prog-plugin-pgsql, ...
> seems like an overkill when prog-binary-... are the only packages that
> are going to use it (even if they're separate and independent). Should
> I pull libprog into the more common binary-A and make binary-B depend
> on it, or should it be split properly like described here?

I think you should split them out as per policy, but I need some
context here to understand why you are saying this.

-- 
dancer@{netfort.gr.jp,debian.org}