Re: mixing different upstream sources in one package
Jay Berkenbilt wrote:
>>From time to time, someone announces an intention to package some tiny
> script or program, and people suggest including it in some other
> package instead to avoid pollution of the archive with lots of tiny
> packages. Although I understand the reasoning and the issues here
> (additional overhead for each package), this has always bothered me a
> little. I'm not sure that, as an upstream author, I would necessarily
> want the debian version of my package to be bundled with other
> software that was similar in functionality but otherwise unrelated to
> my package.
I think this really does depend on size, and on how the tiny program is
used. If the program is really tiny, and it is generally used in
conjunction with your package and by people who use your package, it should
probably be added to your package. Ideally it would be added upstream, and
if not, it can be added to the .diff.gz.
If the program is likely to be used by people who won't be using the rest of
your package, then it's inappropriate to put it in your package. If it's
sufficiently large and complicated that it would trouble the maintenance of
your packages, then you shouldn't put it in your package.
> I've recently taken over maintenance of psutils and am gradually
> working through the outstanding bugs on that package. A few of the
> bugs suggest adding external programs. Assuming there are no other
> impediments (like licensing problems), do people generally think that
> it's reasonable to do this even if the other packages aren't really
> part of the upstream package? If so, are there usual mechanisms for
> doing this?
Put it in the .diff.gz. If it's too large for that to seem reasonable to
you, then you proabably shouldn't put it in your package. :-)