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. -- dan...@{netfort.gr.jp,debian.org} -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org