Re: source dependencies - and recomndations
On %M %N, Joey Hess wrote
> I think we also need a Source-Recommends field. There are some packages that
> should be built with some other package installed, but will build ok without
the main question is :
should we use source dependencies to build the packacke, or to reproduce
the package like the maintainer build it ?
if we only want to build the package, your proposal is ok.
but if we want to generate the same result like the maintainer, we
should require these packages.
> Another example, if pdmenu is built on a systm without libgpm, it will work
> fine, but if built on a system with libgpm, you get mouse support. Both of
> these, and other packages, could use a Source-Recommends field.
if we want to compile pdmenu somehow, Source-Recommends is ok. But if we
want the same result like the maintainer, we need to depend on gpm to
get a pdmenu with mouse support.
we should choose what we want.
if we choose "strong dependencies", still it would be a nice thing to
note "hey, we compile pdmenu with gpm, but you cna also compile pdmenu
pdmenu without mouse support is usefull, but isdnlog without x11 monitor
programs (x11 dep.), without voice box (tcl, ncurses dep.) and without
plain status programs (ncurses dep.) is useless (IMO). but i could build
that. it's hard to decide what to depend and what to recommend.
it's additional work for debian developers to think about that, and in
my opinion, debian will not take advantage from that work, and i don't
think that many users will take advantage of that.
if i compile something, i get the source from sunsite, or only take the
orig.tar.gz. to get these information someone would have to look at the
dsc. and i don't think that many people will look at debian source
changes file (dsc) and still want to compile a different binary.
this is maybe the best example, why debian needs source dependencies.
if i understand joost right, pdmenu will compile without errors, no
matter if gpm is installed or not. but the result will differ.
with source dependencies we can prevent that the result will differ.
we can not support different versions of a package - we have to make
sure, that there is one version of pdmenu, not one with and one without
mouse support, that would confuse users. if we want different packages,
we split a package (like some games come as svgalib and x11 version).
> How this field would be used is the autobuilder would refuse to
> install packages if it couldn't meet the Source-Depends. If it
> couldn't meet the Source-Recommends, it would possibly give a warning,
> but would build the package anyway.
you are right. this is possible. but in my opinion it is not usefull.
this could cause many different versions of isdnutils float around,
and i have much work with one version. supporting several is not
e.g. : in the documentation i will say something about vbox. if tcl
is not present on the build system, the package will compile, but not
build vbox (voice box isdn answering machine). and so i will get bug
reports or other emails from users, that miss vbox and ask me why i
write something in the documentation, try to rotate log files, and don't
ship it in the binary.
supporting one version is enough. in the cases where we want to support
several version, we build two packages (e.g. svgalib and x11 game).
my own proposal :
use "Source-Depends:" and "Source-Recommends:" as you proposed,
but to build the official debian version, you need both installed.
and we only support versions build with both. and splitting into
"Source-Depends:" and "Source-Recommends:" is absolut mandatory, if you
don't think that such a split will help, you can list everything as
Source-Depends:. And if someone decides to compile a package without the
packages in "Source-Recommends", he has no guaranty that the package
will build at all, build fine, or build without errors or without manual
changes. Supporting "Source-Recommends" is the choice of a developer.
We could also list a Source-Alternatives: or so, to note that someone
may use e.g. lex instead of flex or yacc instead of bison. But again :
a developer may make such notes, and support them. But Debian as
distribtuion will not support them. Who wants to track down a bug, to
figure out that someone used a yacc compiled packge instead of the
official debian version compiled with bison ? maybe the developer knows
that compiling with yacc is possible, but might introduce race
conditions. (i don't know lex, yacc, bison or flex - it's only an
what do you think ?
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .