Re: packaging guide questions
> 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.
Well, you said all the pacakges (library + application + plugins) come
from the same source package. If that is true, there is no way to update
only the plugins: each upload, no matter how small the included fixes
are, will have to include all the packages. And then you can just use a
(= ${binary:Version}) depends (assuming there are no arch:all packages
involved; in that case ${source:Version} could be in order).
If they come from different source packages, then it can be done, but
it'd require some debian/rules magic for it to work without having to
specify the version by hand (since eg. the ${source:Upstream-Version} in
the plugin package is not what you'd want without modifying it first).
> > 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.
Unless you have very pressing reasons not to do the split, I think it's
safer to follow what Policy says.
Hope this helps,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
Reply to: